From ra85551 at gmail.com Thu Mar 1 03:47:06 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Thu, 1 Mar 2007 13:47:06 +0300 Subject: [Rxtx] enableReceiveTimeout() issue Message-ID: Hello, world! I found a limitation of 16300 ms for CommPort's enableReceiveTimeout() method, while in original javax.comm docs there are no any references to that. Is that a bug or feature? I actually need longer timeouts sometimees. -- Pavel Parkhomenko From lyon at docjava.com Thu Mar 1 07:54:17 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 01 Mar 2007 09:54:17 -0500 Subject: [Rxtx] parametric singleton design pattern In-Reply-To: References: <22d55aea0702081207q5e7f6785l352d498d6f5f9fb1@mail.gmail.com> <22d55aea0702100034o3bcf42f3j1d1a6257029a67b0@mail.gmail.com> Message-ID: Hi All, I have been thinking about the use of a design pattern to cache resources that are consumed by processes. Toward that end, I have arrived at a parametric singleton design pattern, which I mentioned on this list some time ago. The idea has been published at: http://www.jot.fm/issues/issue_2007_03/column2 I can't help but think that there should be an API available for dealing with the tracking of serial port usage. Perhaps it is a kind of resource manager called the: SerialPortManager basic prototypes already exist in this vain. See, for example: http://www.ce.rit.edu/research/projects/2005_fall/rt_poolsystem/doc/PoolMon/SerialPortManager.html http://www.eventhelix.com/RealtimeMantra/PatternCatalog/serial_port_design_pattern.htm And others shown by a google search on "SerialPortManager" Cheers! - Doug From Eric.Arseneau at sun.com Thu Mar 1 10:15:03 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:15:03 -0800 Subject: [Rxtx] Any known Java 6 issues with RXTX 2.1-7r2 ? Message-ID: <45E70A17.1060206@sun.com> I just did a test on a recent build of Solaris 11 x86 and it seems that I can connect to my serial device fine when Java 5 is the default, but when Java 6 is the default, no go. Any information ? From Eric.Arseneau at sun.com Thu Mar 1 10:19:58 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:19:58 -0800 Subject: [Rxtx] Mac OS X and missing data Message-ID: <45E70B3E.7040908@sun.com> We have a device which is USB based but presents itself as a serial port to a machine. On my MacBook Pro I can get excellent throughput if I get my device to send data as quickly as possible. On the desktop side, if I do an type of disk IO to log the data I get, I end up with some missing data at some point. I hooked up a USB analyzer and did confirm that all the data is sent as expected to the desktop from the device. I found a work around for this, buffer the data in memory and only write the data out when I've received it all. However, when the same code and same device is attempted on a co-workers MacBook Pro (same hardware specs), I get errors and must slow down dramatically the device side's sending of data. Any ideas/recommendations on what I can do to get rid of this error ? From what I can tell, it seems that RXTX is not able to wake up to the interrupts coming in indicating data is ready, quickly enough, is there anything I can do ? From chinkaiw at hotmail.com Fri Mar 2 00:57:43 2007 From: chinkaiw at hotmail.com (Wang Chinkai) Date: Fri, 02 Mar 2007 07:57:43 +0000 Subject: [Rxtx] dynamic detect rs232 port Message-ID: Hi all I have a question about detecting rs232 port dynamicly. I have to aceess some port and detect rs232 port at the same time. Some usb device simulates rs232 port , and I can not know what the port name it gets until it connects,so I have to detect it dynamic,but I have to access another rs232 device at the same time. I found a problem. If I use CommPortIdentifier.getPortIdentifiers() to get new port list , and the other rs232 access function will not close port correctly. So , How can I solve it . Thanks. _________________________________________________________________ ?? 2GB ???? Windows Live Mail ????????????? http://ideas.live.com/programpage.aspx?versionid=5d21c51a-b161-4314-9b0e-4911fb2b2e6d From eu259473 at tele2.it Fri Mar 2 06:16:40 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 02 Mar 2007 14:16:40 +0100 Subject: [Rxtx] rxtx on HP tru 64 unix Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070302/706c7a70/attachment-0088.html From tjarvi at qbang.org Fri Mar 2 08:39:33 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 08:39:33 -0700 (MST) Subject: [Rxtx] rxtx on HP tru 64 unix In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, "Giuseppe Marchese" wrote: > Hi > > I try to install rxtx on hp tru 64 but make fails, > There are somebody that do the same and work. > > > Sorry for may english! > > Hi Giuseppe Could you provide a log of the failure? script ./configure make # use gnu make exit The information will be in the typescript created. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 2 19:56:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 19:56:52 -0700 (MST) Subject: [Rxtx] dynamic detect rs232 port In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, Wang Chinkai wrote: > Hi all > > I have a question about detecting rs232 port dynamicly. > > I have to aceess some port and detect rs232 port at the same time. > Some usb device simulates rs232 port , and I can not know > what the port name it gets until it connects,so I have to detect it > dynamic,but I have to access > another rs232 device at the same time. > > I found a problem. Hi Wang This is a known problem. The code is braindead there. In fact there needs to be events even in a rudamentary way when you add a usb dongle. I'm burried in tasks not far from rxtx but not in rxtx. I can't get to the problem but we would accept patches if you dig into it. [I'm getting to the license question earlier too; I don't have another 10%] -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Fri Mar 2 23:19:01 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 01:19:01 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Hi, Under ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable USB -> serial converter(using virtual com port drivers), with using example code pretty much straight out of http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port opens fine, enumerations all work, etc. My application calls for a large amount of data to be transferred in a short amount of time at 2,000,000 baud. My hardware sends approximately 15,232 bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL converter work fine, and the application works using C++. In C++, I do a hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); to open the port, and a boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); to read the port. The variable buffer fills with the 15238 bytes, and returns. If I do a resultz = is.read(cbuf,0,15238); in java with RXTX where is = new BufferedReader(new InputStreamReader(port.getInputStream())); and where resultz is an int, and cbuf is a char [] cbuf, resultz gets EXACTLY 3968 bytes the first time called. If I call it multiple times, I get roughly 11k total(less than what is sent), never more than the 3968 bytes per is.read() call. My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 bytes. I've played with inputbuffersize, receive threshold, receivetimeout, and so on. The FTDI virtual com port drivers that I'm using are rock solid, and have had zero problems with them using a variety of applications, some of my own, some professionally written, etc. No flow control is used anyplace, no RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. No exceptions are being thrown. What am I doing wrong, and what I can adjust to receive the full 15k bytes in one single read? Thanks! Keith From Eric.Arseneau at sun.com Fri Mar 2 23:32:07 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Fri, 02 Mar 2007 22:32:07 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <45E91667.20501@sun.com> This is the same type of thing that is happening to me on Mac OS X and does not seem to behave the same on different machines. I posted a day or two ago on this with subject "Mac OS X and missing data". Would love to hear if there is a solution to this :) From tjarvi at qbang.org Sat Mar 3 10:54:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 10:54:17 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > Hi, > > Under > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable > USB -> serial converter(using virtual com port drivers), with using example > code pretty much straight out of > http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port > opens fine, enumerations all work, etc. > > My application calls for a large amount of data to be transferred in a short > amount of time at 2,000,000 baud. My hardware sends approximately 15,232 > bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL > converter work fine, and the application works using C++. > > In C++, I do a > > hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, > OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); > > to open the port, and a > > boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); > > to read the port. > > The variable buffer fills with the 15238 bytes, and returns. > > If I do a > > resultz = is.read(cbuf,0,15238); in java with RXTX > > where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > > and where resultz is an int, and cbuf is a char [] cbuf, resultz gets > EXACTLY 3968 bytes the first time called. If I call it multiple times, I get > roughly 11k total(less than what is sent), never more than the 3968 bytes > per is.read() call. > > My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 > bytes. > > I've played with inputbuffersize, receive threshold, receivetimeout, and so > on. The FTDI virtual com port drivers that I'm using are rock solid, and > have had zero problems with them using a variety of applications, some of my > own, some professionally written, etc. No flow control is used anyplace, no > RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. > > No exceptions are being thrown. > > What am I doing wrong, and what I can adjust to receive the full 15k bytes > in one single read? > > Thanks! > Hi Keith I would expect a 20 meg application is going to have different behavior with the OS than a smaller application with respect to the kernel memory managment, schedualing, ... Something subtle could be causing problems. With respect to the recieve timeout and threshold, if you set the timeout to zero and the threshold to the size of data you expect, read should not return until it get that data. You may try with a stand alone application that tests just that with the C/C++ API. If the read is returning with less data when tested for short reads, you have found a bug in the device driver more than likely. The USB dongle vendor would probably be interested in knowing about this. As mentioned, these devices are getting very good; almost bug free. I suspect you found a bug though if you did use the threshold and timeout properly. The missing data is typical when not using flow control. When the OS buffering fills, the hardware will start dropping bytes. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:38:52 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:38:52 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> update: I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now instead of 3968. This makes sense. 128 bytes of overhead + 3968 bytes of data = 4096 transfer size 32 bytes of overhead + 992 bytes of data = 1024 transfer size. 1/4 the data = 1/4 the overhead. I rearranged my reading like so: resultz = is.read(cbuf,0,3968); resultz = is.read(cbuf,3968,3968); resultz = is.read(cbuf,7936,3968); while (!(is.ready())); // wait for ready resultz = is.read(cbuf,11904,3334); and this grabs 15,238 bytes total. BUT, I still have the quandry of the screwed up multi-bytes. I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. Approx 8% of the data. The bad bytes always seem to take the flavor of 0x2018, 0x2019, x2022, x2030, x201d. Are these maybe errors and I don't know what they enumerate to? I still can't believe some other layer isn't handling putting those bytes together all in one stream for me. Thanks Keith ----- Original Message ----- From: "Keith" To: "Bob Jacobsen" ; "RXTX Developers and Users" Sent: Saturday, March 03, 2007 11:26 AM Subject: Re: [Rxtx] is.read() only returning 3968 bytes > Bob, > > > Interesting numerical coincidence is that (max USB transfer) - (what > > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > > needed to transfer that much data. > > I was thinking along the same lines. I don't know USB well, but I do know > that those numbers were close enough to warrant investigating the > relationship between them. > > > I think what you're seeing is the internal buffering of the USB data > > stream. You'll need some form of higher-level buffering to smooth > > that out. > > Shouldn't the InputStreamReader() and BufferedReader() provide this type of > buffering? Isn't that the idea behind those? > > > All hypotheses need to be tested. In this case, a test would be to > > check for missing data. If this idea is right, you'll get _all_ the > > data, but you won't be missing characters. > > I did start looking at the data. -- I'm getting weird results. > > I tried this: > > loopzz = 0; > > for (looptwo = 0; looptwo < 100000; looptwo++) { > while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > > }} > > So I'm reading one character at a time. The good news is that loopzz is > exactly 15238 at the end of the routine, which is perfectly correct. I > picked looptwo value out of thin air. > > The weird results come in terms of the values, the data isn't correct at > least in one case. Look here: > > 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > > This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). > But the 0x89 was replaced by 0x2030. Why the heck would the returned value > be 0x2030?? Why is the returned byte completely out of range? Why the > multibyte return? > > From InputStream in the API: > > read > public abstract int read() > throws IOExceptionReads the next byte of data from the > input stream. The value byte is returned as an int in the range 0 to 255. If > no byte is available because the end of the stream has been reached, the > value -1 is returned. This method blocks until input data is available, the > end of the stream is detected, or an exception is thrown. > Value should be 0-255. > > > In my application time is really critical, reading 1 byte at a time is > probably not going to work. > > Thanks Eric & Bob for looking at this. > > Keith > From tjarvi at qbang.org Sat Mar 3 12:52:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 12:52:27 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > update: > > I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now > instead of 3968. > > This makes sense. > > 128 bytes of overhead + 3968 bytes of data = 4096 transfer size > 32 bytes of overhead + 992 bytes of data = 1024 transfer size. > > 1/4 the data = 1/4 the overhead. > > I rearranged my reading like so: > > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. > Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? > > I still can't believe some other layer isn't handling putting those bytes > together all in one stream for me. > The layer for this in Serial land is flow control. Software and hardware flow control prevent the overruns you observe. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:54:41 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:54:41 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <001a01c75dcd$c8802a70$6600a8c0@jbh757ktruws7g> Trent, Thanks for taking the time to reply. > I would expect a 20 meg application is going to have different behavior > with the OS than a smaller application with respect to the kernel memory > managment, schedualing, ... Something subtle could be causing problems. Well, at least I know the VCP drivers, the OS, etc can handle 2mbps reliably. Without hiccuping or dropping bytes. The C++ code works reliably without flow control. > The missing data is typical when not using flow control. When the OS > buffering fills, the hardware will start dropping bytes. I'm actually not getting MISSING data, I'm getting CORRUPTED data. If you look at my most recent post, I'm getting these bad bytes in place of the correct values: 0x2018, 0x2019, x2022, x2030, x201d. Why would is.read() return values not in the range of 0-255 ? Thanks. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 08:59:14 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 07:59:14 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: At 1:19 AM -0500 3/3/07, Keith wrote: >If I do a > >resultz = is.read(cbuf,0,15238); in java with RXTX > >where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > >and where resultz is an int, and cbuf is a char [] cbuf, resultz gets >EXACTLY 3968 bytes the first time called. If I call it multiple times, I get >roughly 11k total(less than what is sent), never more than the 3968 bytes >per is.read() call. > >My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 >bytes. Interesting numerical coincidence is that (max USB transfer) - (what you get) = 4096-3968 = 128 bytes is (almost) the size of the headers needed to transfer that much data. I think what you're seeing is the internal buffering of the USB data stream. You'll need some form of higher-level buffering to smooth that out. All hypotheses need to be tested. In this case, a test would be to check for missing data. If this idea is right, you'll get _all_ the data, but you won't be missing characters. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 09:26:14 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 11:26:14 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Bob, > Interesting numerical coincidence is that (max USB transfer) - (what > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > needed to transfer that much data. I was thinking along the same lines. I don't know USB well, but I do know that those numbers were close enough to warrant investigating the relationship between them. > I think what you're seeing is the internal buffering of the USB data > stream. You'll need some form of higher-level buffering to smooth > that out. Shouldn't the InputStreamReader() and BufferedReader() provide this type of buffering? Isn't that the idea behind those? > All hypotheses need to be tested. In this case, a test would be to > check for missing data. If this idea is right, you'll get _all_ the > data, but you won't be missing characters. I did start looking at the data. -- I'm getting weird results. I tried this: loopzz = 0; for (looptwo = 0; looptwo < 100000; looptwo++) { while (is.ready()) { cbuf[loopzz] = (char) is.read(); loopzz++; }} So I'm reading one character at a time. The good news is that loopzz is exactly 15238 at the end of the routine, which is perfectly correct. I picked looptwo value out of thin air. The weird results come in terms of the values, the data isn't correct at least in one case. Look here: 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). But the 0x89 was replaced by 0x2030. Why the heck would the returned value be 0x2030?? Why is the returned byte completely out of range? Why the multibyte return? >From InputStream in the API: read public abstract int read() throws IOExceptionReads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown. Value should be 0-255. In my application time is really critical, reading 1 byte at a time is probably not going to work. Thanks Eric & Bob for looking at this. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 14:44:50 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 13:44:50 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: Java's "char" type is Unicode. I think what you're seeing is a bug in the byte -> Unicode translation. 0x2018, 0x2019 are the curly open and close quotes. There used to be (and might still be) bugs in the conversion of these in a couple of libc versions. Some of the ASCII -> ISO and ISO -> ASCII routines were a little over-ambitious with respect to handling the open and close quotes, and tried to convert them to the "curly" form inappropriately. Try _not_ casting it to char. Bob At 11:26 AM -0500 3/3/07, Keith wrote: >Bob, > >> Interesting numerical coincidence is that (max USB transfer) - (what >> you get) = 4096-3968 = 128 bytes is (almost) the size of the headers >> needed to transfer that much data. > >I was thinking along the same lines. I don't know USB well, but I do know >that those numbers were close enough to warrant investigating the >relationship between them. > >> I think what you're seeing is the internal buffering of the USB data >> stream. You'll need some form of higher-level buffering to smooth >> that out. > >Shouldn't the InputStreamReader() and BufferedReader() provide this type of >buffering? Isn't that the idea behind those? > >> All hypotheses need to be tested. In this case, a test would be to >> check for missing data. If this idea is right, you'll get _all_ the >> data, but you won't be missing characters. > >I did start looking at the data. -- I'm getting weird results. > >I tried this: > >loopzz = 0; > >for (looptwo = 0; looptwo < 100000; looptwo++) { >while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > >}} > >So I'm reading one character at a time. The good news is that loopzz is >exactly 15238 at the end of the routine, which is perfectly correct. I >picked looptwo value out of thin air. > >The weird results come in terms of the values, the data isn't correct at >least in one case. Look here: > >0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > >This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). >But the 0x89 was replaced by 0x2030. Why the heck would the returned value >be 0x2030?? Why is the returned byte completely out of range? Why the >multibyte return? > >>From InputStream in the API: > >read >public abstract int read() > throws IOExceptionReads the next byte of data from the >input stream. The value byte is returned as an int in the range 0 to 255. If >no byte is available because the end of the stream has been reached, the >value -1 is returned. This method blocks until input data is available, the >end of the stream is detected, or an exception is thrown. >Value should be 0-255. > > >In my application time is really critical, reading 1 byte at a time is >probably not going to work. > >Thanks Eric & Bob for looking at this. > >Keith > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 15:10:11 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 17:10:11 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Bob said ..... > Java's "char" type is Unicode. I think what you're seeing is a bug > in the byte -> Unicode translation. Bob -- I think you hit the nail on the head. I was just coming to the same realization here. I knew that something funny was going on because the same bytes always got "corrupted." I'm pretty sure its in the InputStreamReader() functionality where the conversion junk is happening. Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. I don't know if simply changing the cast is going to work. Since the conversion is happening upstream (pun intended), I don't think my cast is doing this. Also I think the compiler forced me to use the cast. I'm still playing around, and I'll report back once I nail it down. Thanks!! Keith From tjarvi at qbang.org Sat Mar 3 15:59:46 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 15:59:46 -0700 (MST) Subject: [Rxtx] Win64 rxtx Testers? Message-ID: I have compiled win64 binaries of rxtx. Are there any users interested in testing them? If so, I'll look into putting them on the web site. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Mar 3 15:35:06 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 14:35:06 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: Because of this and similar problems, JMRI does all it's serial IO using +only+ byte values. It's a but of a pain, as Java wants to go to char and int types a little too aggressively, but it does solve the "uncontrolled conversions" problems. Bob At 5:10 PM -0500 3/3/07, Keith wrote: >Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > >Bob -- I think you hit the nail on the head. > >I was just coming to the same realization here. I knew that something funny >was going on because the same bytes always got "corrupted." > >I'm pretty sure its in the InputStreamReader() functionality where the >conversion junk is happening. > >Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > >I don't know if simply changing the cast is going to work. Since the >conversion is happening upstream (pun intended), I don't think my cast is >doing this. Also I think the compiler forced me to use the cast. -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mark at mdsh.com Sun Mar 4 11:01:33 2007 From: mark at mdsh.com (Mark Himsley) Date: Sun, 04 Mar 2007 18:01:33 +0000 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: <5C01AC72C200388815C04982@bedroom.mdsh.local> On 03 March 2007 14:38 -0500 Keith wrote: > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT > consistent. Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? It looks like you need to use DataInputStream and DataOutputStream. -- Mark Himsley From tjarvi at qbang.org Sun Mar 4 11:35:08 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 11:35:08 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" > > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > > * Line #21 - Not sure if you need a (TM) mark for > the term "Sun" > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > OK. I'm going through this today. Some groups ask if rxtx could be under their license also. I think this is a good example of why I resist multiple licenses and focus on why the current license may not be usable by them. The RXTX project is a convergence of hobby and commercial interests. I happen to do both right now. The problem with licensing is we have to stay on top of them as they change. Clearly, adding more licenses will not make this easier. I'm acting as the hobby person today. RXTX always favors the hobby people. But as we move forward, I'm going to need to bring this to lawyers at work and explain to them what is going on. Others here may have to do this also. I don't anticipate problems or unexpected changes. The goal is a consistant, comprehendable and usable license as close to what we have now as possible. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 14:52:10 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 14:52:10 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (1/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: I'm breaking this into two parts. I expect the second part will need more attention. Comments first, then the changed material below. On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > Thanks > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. OK. RXTX for consitent use. java should not be capitalized because it does not only mean Sun [TM] Java [TM]. An example of this not meaning Java is when people use RXTX with GCJ. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". There are not any contributors that are in all of RXTX yet but I did update the comment to try to reflect the current situation without making it a nightmare to maintain. I looked to see how the Linux kernel does it as a reference point. > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" The URL can be problematic. I have done so below with a time reference. GNU does not provide version information in their URLS. I picture this being a problem when the version 3 comes out. > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > This will be corrected when the copy is updated to the version linked below. ---------------- begin proposed material involved -------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. ----------------- end proposed material involved -------------------- I'll be looking at the linking issue again next. That should be all that remains other than including the 2.1 version. Let me know if you have problems with anything here. I do not want to dilute the material I post next with these housekeeping tasks. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 16:08:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 16:08:36 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: For those that are wondering what is going on here, this next bit is the meat of the changes. We agreed a long time ago to put this disclaimer in. We did a so so job. It was in rxtx 2.0, not well written, ... So some groups using rxtx that would like to ship rxtx so users don't need to download, install, go to the mail-list to find why it failed, ... Then their legal teams tell them section 5 paragraph 2 is a show stopper. That was never the intent. Now going through what remains... > and might need a (TM) suffix to make Sun happy. Added disclaimer at the ended 'all trademarks belong...' > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. OK. As you can see I was trying to adjust GNU text there for the LGPL. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. used dynamically linked terminology. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". I tried to address this more upfront with an intent statement. Let me know if you have problems with it. I also tried to make it a little more clear what was derived from the GNU solution by moving the link location closer to GNU's suggestion. > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > Thats the intent. Here is the combined fixes. Note that only the material in /*-- --*/ is being touched. The new GPL license is there but unmodified. ------------------------ begin proposed new license ------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. | | An executable that contains no derivative of any portion of RXTX, but | is designed to work with RXTX by being dynamically linked with it, | is considered a "work that uses the Library" subject to the terms and | conditions of the GNU Lesser General Public License. | | The following has been added to the RXTX License to remove | any confusion about linking to RXTX. We want to allow in part what | section 5, paragraph 2 of the LGPL does not permit in the special | case of linking over a controlled interface. The intent is to add a | Java Specification Request or standards body defined interface in the | future as another exception but one is not currently available. | | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface | | As a special exception, the copyright holders of RXTX give you | permission to link RXTX with independent modules that communicate with | RXTX solely through the Sun Microsytems CommAPI interface version 2, | regardless of the license terms of these independent modules, and to copy | and distribute the resulting combined work under terms of your choice, | provided that every copy of the combined work is accompanied by a complete | copy of the source code of RXTX (the version of RXTX used to produce the | combined work), being distributed under the terms of the GNU Lesser General | Public License plus this exception. An independent module is a | module which is not derived from or based on RXTX. | | Note that people who make modified versions of RXTX are not obligated | to grant this special exception for their modified versions; it is | their choice whether to do so. The GNU Lesser General Public License | gives permission to release a modified version without this exception; this | exception also makes it possible to release a modified version which | carries forward this exception. | | You should have received a copy of the GNU Lesser General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA | All trademarks belong to their respective owners. --------------------------------------------------------------------------*/ The original GNU Lesser General Public License Follows. GNU LESSER GENERAL PUBLIC LICENSE Version 2.1, February 1999 Copyright (C) 1991, 1999 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. [This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence the version number 2.1.] Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This license, the Lesser General Public License, applies to some specially designated software packages--typically libraries--of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below. When we speak of free software, we are referring to freedom of use, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish); that you receive source code or can get it if you want it; that you can change the software and use pieces of it in new free programs; and that you are informed that you can do these things. To protect your rights, we need to make restrictions that forbid distributors to deny you these rights or to ask you to surrender these rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library or if you modify it. For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights. We protect your rights with a two-step method: (1) we copyright the library, and (2) we offer you this license, which gives you legal permission to copy, distribute and/or modify the library. To protect each distributor, we want to make it very clear that there is no warranty for the free library. Also, if the library is modified by someone else and passed on, the recipients should know that what they have is not the original version, so that the original author's reputation will not be affected by problems that might be introduced by others. Finally, software patents pose a constant threat to the existence of any free program. We wish to make sure that a company cannot effectively restrict the users of a free program by obtaining a restrictive license from a patent holder. Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license. Most GNU software, including some libraries, is covered by the ordinary GNU General Public License. This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs. When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library. We call this license the "Lesser" General Public License because it does Less to protect the user's freedom than the ordinary General Public License. It also provides other free software developers Less of an advantage over competing non-free programs. These disadvantages are the reason we use the ordinary General Public License for many libraries. However, the Lesser license provides advantages in certain special circumstances. For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License. In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software. For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU operating system, as well as its variant, the GNU/Linux operating system. Although the Lesser General Public License is Less protective of the users' freedom, it does ensure that the user of a program that is linked with the Library has the freedom and the wherewithal to run that program using a modified version of the Library. The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, whereas the latter must be combined with the library in order to run. GNU LESSER GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License Agreement applies to any software library or other program which contains a notice placed by the copyright holder or other authorized party saying it may be distributed under the terms of this Lesser General Public License (also called "this License"). Each licensee is addressed as "you". A "library" means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables. The "Library", below, refers to any such software library or work which has been distributed under these terms. A "work based on the Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term "modification".) "Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library. Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does. 1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) The modified work must itself be a software library. b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change. c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License. d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful. (For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library. In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. 4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange. If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code. 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables. When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law. If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.) Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself. 6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications. You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things: a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.) b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. c) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution. d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place. e) Verify that the user has already received a copy of these materials or that you have already sent this user a copy. For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute. 7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things: a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above. b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work. 8. You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 9. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Library (or any work based on the Library), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Library or works based on it. 10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties with this License. 11. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply, and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 12. If the distribution and/or use of the Library is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Library under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 13. The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation. 14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Libraries If you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the ordinary General Public License). To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Also add information on how to contact you by electronic and paper mail. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the library, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the library `Frob' (a library for tweaking knobs) written by James Random Hacker. , 1 April 1990 Ty Coon, President of Vice That's all there is to it! ------------------------ end of proposed license ------------------ -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sun Mar 4 16:26:04 2007 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 04 Mar 2007 17:26:04 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <45EB558C.3010609@cox.net> Bob Jacobsen wrote: > Because of this and similar problems, JMRI does all it's serial IO > using +only+ byte values. It's a but of a pain, as Java wants to go > to char and int types a little too aggressively, but it does solve > the "uncontrolled conversions" problems. Anytime that you are reading bytes of data that is not printable, unicode text, in Java, you really need to stay away from the Readers. Use input stream only, or you will see unicode valued byte groups converted to unicode "char" values. Gregg Wonderly From joachim at buechse.de Mon Mar 5 04:23:48 2007 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 5 Mar 2007 12:23:48 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> The behaviour is exactly what you asked for in you code. is = new BufferedReader(new InputStreamReader(port.getInputStream())); Readers return Text (ie unicode chars) not bytes. You instantiate the InputStreamReader without saying which charset you want, which means "platform default". As this is on Windows, it will convert Windows characters to equivalent unicode characters. If you want to read bytes, read bytes not Text. Reading bytes is done with InputStream and BufferedInputStream. BTW: The InputStream and Reader methods that read arrays are not guarenteed to fill up the array. You always have to check what you really got, and advance your index accordingly. A typical "read up to 32k" method looks like this: InputStream is= ... // -- determine the max buffer size int len= is.available(); if (len == 0) { len= 32 * 1024; } // -- read all available data byte[] buffer= new byte[len]; int pos= 0; int read; do { read= is.read(buffer, pos, buffer.length - pos); pos= pos + read; } while (read != -1 && pos < buffer.length); Best regards, Joachim --- Joachim B?chse Phone: +41 44 500 2604 Buechse Consulting Hadlaubsteig 2 CH-8006 Z?rich On 03.03.2007, at 23:10, Keith wrote: > Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > > Bob -- I think you hit the nail on the head. > > I was just coming to the same realization here. I knew that > something funny > was going on because the same bytes always got "corrupted." > > I'm pretty sure its in the InputStreamReader() functionality where the > conversion junk is happening. > > Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > > I don't know if simply changing the cast is going to work. Since the > conversion is happening upstream (pun intended), I don't think my > cast is > doing this. Also I think the compiler forced me to use the cast. > > I'm still playing around, and I'll report back once I nail it down. > > Thanks!! > > Keith > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Mon Mar 5 07:25:46 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 05 Mar 2007 08:25:46 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> Message-ID: <45EC286A.8060608@cox.net> Joachim Buechse wrote: > BTW: The InputStream and Reader methods that read arrays are not > guarenteed to fill up the array. You always have to check what you > really got, and advance your index accordingly. A typical "read up to > 32k" method looks like this: > > InputStream is= ... > // -- determine the max buffer size > int len= is.available(); > if (len == 0) { > len= 32 * 1024; > } > // -- read all available data > byte[] buffer= new byte[len]; > int pos= 0; > int read; > do { > read= is.read(buffer, pos, buffer.length - pos); > pos= pos + read; > } while (read != -1 && pos < buffer.length); > My preferred structure is. byte arr[ len ]; int cnt; int off = 0; while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { off += cnt; } This keeps you from adding -1 to pos when the read returns -1. It also skips out when the read is 0 bytes which, is not a described EOF in InputStream java docs, but is a condition I want to be aware of. Gregg Wonderly From joachim at buechse.de Tue Mar 6 02:52:58 2007 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 6 Mar 2007 10:52:58 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <45EC286A.8060608@cox.net> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: The code I copied was from a file resource reader, it shouldn't really be applied to networking/external IO code. Mea culpa. However aborting when you get 0 from read is not always what you want either (you kind of indicated that already). Some unix java implementations will return 0 if the kernel read was aborted with EINTER, which is rarely the point where you want to abort your read - at least not without further checks. A "complete" solution always depends on the events you need to handle and the time the total read could take in reality. In some cases it's worth checking Thread.isInterrupted() in the loop, some code re-loops on 0 but only a limited number of times, some check a total timeout limit, etc... Best regards, Joachim On 05.03.2007, at 15:25, Gregg Wonderly wrote: > My preferred structure is. > > byte arr[ len ]; > int cnt; > int off = 0; > while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { > off += cnt; > } > > This keeps you from adding -1 to pos when the read returns -1. It > also skips > out when the read is 0 bytes which, is not a described EOF in > InputStream java > docs, but is a condition I want to be aware of. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Mar 6 14:47:44 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 Mar 2007 14:47:44 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: Just FYI, rxtx will usually not break out on EINTER. The code in the native library usually does something close to this: do { read(...) } while ( !done && errno==EINTR ); Obviously there is a little more involved but it will retry on EINTER if not done. On Tue, 6 Mar 2007, Joachim Buechse wrote: > The code I copied was from a file resource reader, it shouldn't > really be applied to networking/external IO code. Mea culpa. > > However aborting when you get 0 from read is not always what you want > either (you kind of indicated that already). Some unix java > implementations will return 0 if the kernel read was aborted with > EINTER, which is rarely the point where you want to abort your read - > at least not without further checks. A "complete" solution always > depends on the events you need to handle and the time the total read > could take in reality. In some cases it's worth checking > Thread.isInterrupted() in the loop, some code re-loops on 0 but only > a limited number of times, some check a total timeout limit, etc... > > Best regards, > Joachim > > On 05.03.2007, at 15:25, Gregg Wonderly wrote: >> My preferred structure is. >> >> byte arr[ len ]; >> int cnt; >> int off = 0; >> while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { >> off += cnt; >> } >> >> This keeps you from adding -1 to pos when the read returns -1. It >> also skips >> out when the read is 0 bytes which, is not a described EOF in >> InputStream java >> docs, but is a condition I want to be aware of. >> >> Gregg Wonderly >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 gjhanna at gmail.com Thu Mar 8 13:42:52 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Fri, 9 Mar 2007 09:42:52 +1300 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? Message-ID: I've just struck an issue using rxtx in a multi-threaded environment: If I have 3 threads trying to open *the same* comm-port I get a deadlock in CommPortIdentifier.open If I have just 2, it works fine - I get a PortInUseException which is nice and I can handle it. The 3 thread->deadlock thing is causing me issues. (Sample code below). This is from the java thread-dump Found one Java-level deadlock: ============================= "Thread-2": waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object ), which is held by "Thread-1" "Thread-1": waiting to lock monitor 0x0003e9cc (object 0x2450e108, a gnu.io.CommPortIdentifier), which is held by "Thread-2" Java stack information for the threads listed above: =================================================== "Thread-2": at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:329) - waiting to lock <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) "Thread-1": at java.lang.Object.wait(Native Method) - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) - locked <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) (Apart from this, rxtx is working fantastically for us). I'm thinking I'll have to implement some sort of locking mechanism that *doesn't* use java synchronization to prevent this situation. (Which doesn't sound like a good idea to me). Any ideas? Thanks, Greg Hanna ============= RXTXLockTest.java ======================================== import gnu.io.CommPort; import gnu.io.CommPortIdentifier; /** * @author Greg Hanna * Minimal code to create a deadlock with rxtx in multithreaded open */ public class RXTXLockTest { public static void main(String[] args) { try { CommPortIdentifier cpiCom1 = CommPortIdentifier.getPortIdentifier ("COM14"); OpenThread t1 = new OpenThread (" one ", cpiCom1); OpenThread t2 = new OpenThread (" two ", cpiCom1); OpenThread t3 = new OpenThread (" 003 ", cpiCom1); t1.start(); t2.start(); t3.start(); // comment this out and it runs with (expected) PortInUseException } catch (Exception e) { e.printStackTrace(); } } } class OpenThread extends Thread { String name; CommPortIdentifier cpi; CommPort cp; public OpenThread (String name, CommPortIdentifier cpi) { this.name = name; this.cpi = cpi; System.out.println (System.currentTimeMillis() + name + " thread created"); } public void run () { try { System.out.println (System.currentTimeMillis() + name + " opening"); cp = cpi.open(name, 2000); System.out.println (System.currentTimeMillis() + name + " opened - sleeping"); sleep (2000); // do the serial comms with the device. System.out.println (System.currentTimeMillis() + name + " slept - closing"); cp.close(); System.out.println (System.currentTimeMillis() + name + " closed - exiting"); } catch (Exception e) { System.out.println ("Error in thread: " + name ); e.printStackTrace(); } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070308/d9a163c5/attachment-0081.html From eu259473 at tele2.it Fri Mar 9 02:46:20 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 09 Mar 2007 10:46:20 +0100 Subject: [Rxtx] rxtx: tru64 unix make fails Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070309/3b654523/attachment-0081.html From lyon at docjava.com Fri Mar 9 03:58:32 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 Mar 2007 05:58:32 -0500 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi All, The deadlock issue is one that I have been thinking about for some time now. It seems to me that we need a resource manager that enables assignment to a known process. The one thing that seems important about serial ports is that two applications should not use the same serial port at the same time. When this happens, it throws an exception. OK. The exception is a response to a lock condition that arises from an unavailable resource. An abstract implementation (not born of native methods) might assign a serial port to an application, until the application releases it (or is forced to release it by some kill mechanism). Some resources (like a registry) can be reused. But others, like the serial port, cannot. In the case of the serial port, we would like, I think, to have the flyweight design pattern without sharing and with object assignment tracking. A means of breaking deadlock (like a leasing mechanism) seems very useful, to me. My guess is that we can serialize the state of the Parametric Singleton Pattern (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) into the Preferences of the System. Preferences.systemRoot() might help with that. When a resource is checked out, the lease time and owner are listed. A thread that does this can be killed, but applications outside of Java are problematic. There is a compelling problem here. It is not just serial ports. Sound cards, cameras, microphones, files, tape drives, etc. All are consumed resources that are assigned to an application (or user) and deprive other applications, or users, from use. What, if anything, should we do? At present we throw PortInUseExceptions. Is that it? Can we do better? OK, the port is in use. Now what? Do I have to be root to go remove lock files and kill applications? Is there a better way? Thanks! - Doug >I've just struck an issue using rxtx in a multi-threaded environment: > >If I have 3 threads trying to open *the same* >comm-port I get a deadlock in >CommPortIdentifier.open >If I have just 2, it works fine - I get a >PortInUseException which is nice and I can >handle it. > >The 3 thread->deadlock thing is causing me issues. >(Sample code below). > >This is from the java thread-dump > >Found one Java-level deadlock: >============================= >"Thread-2": > waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), > which is held by "Thread-1" >"Thread-1": > waiting to lock monitor 0x0003e9cc (object >0x2450e108, a gnu.io.CommPortIdentifier ), > which is held by "Thread-2" > >Java stack information for the threads listed above: >=================================================== >"Thread-2": > at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) > - waiting to lock <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) >"Thread-1": > at java.lang.Object.wait(Native Method) > - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) > - locked <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) > > >(Apart from this, rxtx is working fantastically for us). > >I'm thinking I'll have to implement some sort of >locking mechanism that *doesn't* use java >synchronization to prevent this situation. >(Which doesn't sound like a good idea to me). > >Any ideas? > >Thanks, > >Greg Hanna > >============= RXTXLockTest.java ======================================== > >import gnu.io.CommPort; >import gnu.io.CommPortIdentifier; > >/** > * @author Greg Hanna > * Minimal code to create a deadlock with rxtx in multithreaded open > */ >public class RXTXLockTest { > ? > ?public static void main(String[] args) { > ?try { > ?CommPortIdentifier cpiCom1 = >CommPortIdentifier.getPortIdentifier ("COM14"); > ?OpenThread t1 = new OpenThread (" one ", cpiCom1); > ?OpenThread t2 = new OpenThread (" two ", cpiCom1); > ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); > ?t1.start(); > ?t2.start(); > ?t3.start(); // comment this out >and it runs with (expected) PortInUseException > ?} catch (Exception e) { > ?e.printStackTrace(); > ?} > ?} >} > >class OpenThread extends Thread { > ?String name; > ?CommPortIdentifier cpi; > ?CommPort cp; > ?public OpenThread (String name, CommPortIdentifier cpi) { > ? this.name = name; > ?this.cpi = cpi; > ?System.out.println >(System.currentTimeMillis() + name + " thread >created"); > ?} > ?public void run () { > ?try { > ?System.out.println >(System.currentTimeMillis() + name + " opening"); > ?cp = cpi.open(name, 2000); > ?System.out.println >(System.currentTimeMillis() + name + " opened - >sleeping"); > ?sleep (2000); // do the serial comms with the device. > ?System.out.println >(System.currentTimeMillis() + name + " slept - >closing"); > ?cp.close(); > ?System.out.println >(System.currentTimeMillis() + name + " closed - >exiting"); > ?} catch (Exception e) { > System.out.println ("Error in thread: " + name ); > ?e.printStackTrace(); > ?} > ?} >} > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Mar 9 06:37:45 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 Mar 2007 06:37:45 -0700 (MST) Subject: [Rxtx] rxtx: tru64 unix make fails In-Reply-To: References: Message-ID: On Fri, 9 Mar 2007, "Giuseppe Marchese" wrote: > Sorry for delay. > ? > This is log for ./configure and make > error. > ? > thanks for attention > ? > Make: '%.java,$(TOP)/$(CLASSDEST)/%.class,$(wildcard $(SPATH)/*.java)': extra chars.? > Stop. > Hi Giuseppe You need to use GNU make with the Makefile. I suspect the tru64 make is not happy with those rules. > configure: exit 0 Looks like configure is fairly happy. From tjarvi at qbang.org Sat Mar 10 07:43:51 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 07:43:51 -0700 (MST) Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi Doug I have very little time to look into this further but what we could do is open up an rxtx 3 devel branch in which a proof of concept could be worked on. It could be the proof of concept for a JSR others including Sun could look at/work on or parts of it could be recycled in a JSR. I'm working very hard on rxtx right now but it does not show. I'm looking at win64, mac intel/ppc, usb bluetooth and usb serial dongles. Some are going to be more tested than others but they are all on the plate. I'll be pushing all the fixes upstream when they are done. So I'm very busy in 2.1 but we could open a new branch. On Fri, 9 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > The deadlock issue is one that I have been thinking about > for some time now. > It seems to me that we need a resource manager that enables assignment > to a known process. > > The one thing that seems important about serial > ports is that two applications should not use the > same serial port at the same time. When this > happens, it throws an exception. > OK. > > The exception is a response to a lock condition that > arises from an unavailable resource. > > An abstract implementation (not born of native methods) might > assign a serial port to an application, until the > application releases it (or is forced to release > it by some kill mechanism). > > Some resources (like a registry) can be reused. > But others, like the serial port, > cannot. > > In the case of the serial port, we would like, I think, to > have the flyweight design pattern > without sharing and with object assignment tracking. > A means of breaking deadlock (like a leasing > mechanism) seems very useful, to me. > > My guess is that we can serialize the state of the Parametric Singleton Pattern > (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) > into the Preferences of the System. Preferences.systemRoot() might help > with that. When a resource is checked out, the lease time and owner are > listed. A thread that does this can be killed, but applications outside of Java > are problematic. > > There is a compelling problem here. It is not just serial ports. > Sound cards, cameras, microphones, files, tape drives, etc. All are consumed > resources that are assigned to an application (or > user) and deprive other applications, > or users, from use. > > What, if anything, should we do? At present we throw PortInUseExceptions. > Is that it? > Can we do better? > OK, the port is in use. Now what? > Do I have to be root to go remove lock files and kill applications? > Is there a better way? > > Thanks! > - Doug > >> I've just struck an issue using rxtx in a multi-threaded environment: >> >> If I have 3 threads trying to open *the same* >> comm-port I get a deadlock in >> CommPortIdentifier.open >> If I have just 2, it works fine - I get a >> PortInUseException which is nice and I can >> handle it. >> >> The 3 thread->deadlock thing is causing me issues. >> (Sample code below). >> >> This is from the java thread-dump >> >> Found one Java-level deadlock: >> ============================= >> "Thread-2": >> waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), >> which is held by "Thread-1" >> "Thread-1": >> waiting to lock monitor 0x0003e9cc (object >> 0x2450e108, a gnu.io.CommPortIdentifier ), >> which is held by "Thread-2" >> >> Java stack information for the threads listed above: >> =================================================== >> "Thread-2": >> at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) >> - waiting to lock <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> "Thread-1": >> at java.lang.Object.wait(Native Method) >> - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) >> - locked <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> >> >> (Apart from this, rxtx is working fantastically for us). >> >> I'm thinking I'll have to implement some sort of >> locking mechanism that *doesn't* use java >> synchronization to prevent this situation. >> (Which doesn't sound like a good idea to me). >> >> Any ideas? >> >> Thanks, >> >> Greg Hanna >> >> ============= RXTXLockTest.java ======================================== >> >> import gnu.io.CommPort; >> import gnu.io.CommPortIdentifier; >> >> /** >> * @author Greg Hanna >> * Minimal code to create a deadlock with rxtx in multithreaded open >> */ >> public class RXTXLockTest { >> ? >> ?public static void main(String[] args) { >> ?try { >> ?CommPortIdentifier cpiCom1 = >> CommPortIdentifier.getPortIdentifier ("COM14"); >> ?OpenThread t1 = new OpenThread (" one ", cpiCom1); >> ?OpenThread t2 = new OpenThread (" two ", cpiCom1); >> ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); >> ?t1.start(); >> ?t2.start(); >> ?t3.start(); // comment this out >> and it runs with (expected) PortInUseException >> ?} catch (Exception e) { >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> class OpenThread extends Thread { >> ?String name; >> ?CommPortIdentifier cpi; >> ?CommPort cp; >> ?public OpenThread (String name, CommPortIdentifier cpi) { >> ? this.name = name; >> ?this.cpi = cpi; >> ?System.out.println >> (System.currentTimeMillis() + name + " thread >> created"); >> ?} >> ?public void run () { >> ?try { >> ?System.out.println >> (System.currentTimeMillis() + name + " opening"); >> ?cp = cpi.open(name, 2000); >> ?System.out.println >> (System.currentTimeMillis() + name + " opened - >> sleeping"); >> ?sleep (2000); // do the serial comms with the device. >> ?System.out.println >> (System.currentTimeMillis() + name + " slept - >> closing"); >> ?cp.close(); >> ?System.out.println >> (System.currentTimeMillis() + name + " closed - >> exiting"); >> ?} catch (Exception e) { >> System.out.println ("Error in thread: " + name ); >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 mm at UDel.Edu Sat Mar 10 14:48:32 2007 From: mm at UDel.Edu (Mike Markowski) Date: Sat, 10 Mar 2007 16:48:32 -0500 Subject: [Rxtx] rxtx and Sun's comm api Message-ID: <45F327B0.2060004@udel.edu> Hi all, I joined the list a few days ago and apologize for what is likely a frequently asked question, though I haven't yet found it anywhere. I learned about rxtx.org through the readme on Sun's version 2 of their comms api. They give recommendations in that readme regarding how a better comms api should be written. Is this the aim of rxtx.org? I wrote an app on my linux box using the Sun comms api (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the fact that only linux and Solaris are supported. So I'm glad to find rxtx.org and am just reading up on how make the conversion so Windows users will be able to run the program as well. At the same time I'm just curious if rxtx.org and Sun are both heading in the same direction. Thanks for any background or historical info. Feel free to point me to any www pages if my googling has just completely missed the target! Thanks again, Mike From tjarvi at qbang.org Sat Mar 10 15:35:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 15:35:25 -0700 (MST) Subject: [Rxtx] rxtx and Sun's comm api In-Reply-To: <45F327B0.2060004@udel.edu> References: <45F327B0.2060004@udel.edu> Message-ID: On Sat, 10 Mar 2007, Mike Markowski wrote: > Hi all, > > I joined the list a few days ago and apologize for what is likely a > frequently asked question, though I haven't yet found it anywhere. I > learned about rxtx.org through the readme on Sun's version 2 of their > comms api. They give recommendations in that readme regarding how a > better comms api should be written. Is this the aim of rxtx.org? > > I wrote an app on my linux box using the Sun comms api > (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the > fact that only linux and Solaris are supported. So I'm glad to find > rxtx.org and am just reading up on how make the conversion so Windows > users will be able to run the program as well. At the same time I'm > just curious if rxtx.org and Sun are both heading in the same direction. > > Thanks for any background or historical info. Feel free to point me to > any www pages if my googling has just completely missed the target! > I do not have any news (good or bad) concerning RXTX and Sun working together but perhaps others here do. The main goal of RXTX is to expose POSIX termios interfaces to java users. The future support of javax.comm is questionable. We do not have resources for everything. gnu.io (RXTX 2.1) will be supported going forward and functions the same as CommAPI 2.0. If you have control of the source code you are working with, I would not advise using CommAPI 2.0 javax.comm. We do support CommAPI 2.0 javax.comm for older applications but I do not think that will last much longer for practical reasons. The download interest in CommAPI 2.0 javax.comm support is becomming negligible on this end. There has been discussion of a JSR effort but I do not know of any status change since it was mentioned. One problem with a JSR is that even a light weight process is going to be difficult for RXTX at this time. Maybe that will change in the future but then again it may not. For now, we are just going forward 'as is' in rxtx 2.1 with package gnu.io while trying as a secondary effort to backport the changes to rxtx 2.0 for javax.comm support for users that do not have a choice. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Mar 11 07:19:40 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 11 Mar 2007 08:19:40 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: Hi All, I have been a proponent of a JSR that makes use of RXTX. I have executed the proper agreements with Sun. At this point we are in the: Early Draft Review of Draft Specifications Stage. The best thing to do is to enter the quiet period and create a specification. The question of exactly how we, as a group, want to approach this problem, remains open. Typically, we should have both a specification and a reference implementation. Thus, it would be to our best advantage to have a nice, stable, cross platform RXTX distro that adheres to the groups specification. Now, from a specification standpoint, my personal view on the matter is that we create a series of interfaces, with nice documentation (or at least javadoc). Is this a good idea? Should we have a pure interface specification for the communication API? There are several issues, in my mind, which still weigh on us. Hot-pluggable dongles, long discovery process on pop-up ports, lack of uniformity on device names, lack of uniformity on locking, a precise understanding of how the SerialPortResourceManager works (or even if we should have one). The more questions we answer in our reference implementation, the better our specification will get. RXTX is a good working prototype, but, I don't know if that is what we want to use for a specification. Here is what I have for a CommPortInterface: */ public interface CommPortInterface { /** * @return a string representation of this port. */ String toString(); /** * Gets the name of the communications port. This name should correspond to * something the user can identify, like the label on the hardware. * @return name of the port */ String getName(); /** * @return an input stream that can be used to read data from the * communications port. If the port doesn't support reading data, this * method returns null. *

* The blocking behaviour of this input stream depends on the threshold * and timeout values, as shown below for a read buffer size of n * bytes: * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ThresholdTimeoutBlocking behaviour
StateValueStateValue
disableddisabledblock until data is available
enabledm bytesdisabledblock until min(m, n) bytes are available
disabledenabledt msblock for t ms or until data is available
enabledm bytesenabledt msblock for t ms or until min(m, n) bytes are * available
* @throws java.io.IOException */ InputStream getInputStream() throws IOException; /** * @return an output stream that can be used to send data to the * communications port. If the port doesn't support sending data, this * method returns null. * @throws java.io.IOException */ OutputStream getOutputStream() throws IOException; /** * Closes this communications port. * All PortOwnershipListeners will be? * notified of this change of ownership. Further method calls on this? * object will throw IllegalStateException. Further calls on the? * associated InputStream or OutputStream will throw IOException. *

* Close does not block. Undelivered data is discarded. Blocked read and? * write operations are aborted if the underlying operating systems? * supports an IO abort mechanism. To await the delivery of undelivered? * data call OutputStream.flush() or OutputStream.close() before calling? * Port.close(). */ void close(); /** * Enables receive threshold. * When the specified threshold number of bytes are retrieved, read will * return immediately. * * @param thresh the number of bytes in the input buffer * @throws gnu.io.UnsupportedCommOperationException * if receive threshold is * not supported by the driver * @see #disableReceiveThreshold */ void enableReceiveThreshold(int thresh) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive threshold. * * @see #enableReceiveThreshold */ void disableReceiveThreshold(); /** * @return true if receive threshold is enabled. * * @see #enableReceiveThreshold */ boolean isReceiveThresholdEnabled(); /** * @return the receive threshold value. If receive threshold is diabled * or not supported, this value is meaningless. * * @see #enableReceiveThreshold */ int getReceiveThreshold(); /** * Enables receive timeout. * When the specified number of milliseconds have elapsed, read will * return immediately. * * @param rcvTimeout the number of milliseconds to block for * @throws gnu.io.UnsupportedCommOperationException * if receive timeout is * not supported by the driver * @see #disableReceiveTimeout */ void enableReceiveTimeout(int rcvTimeout) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive timeout. * * @see #enableReceiveTimeout */ void disableReceiveTimeout(); /** * @return true if receive timeout is enabled. * * @see #enableReceiveTimeout */ boolean isReceiveTimeoutEnabled(); /** * @return the receive timeout value. If receive timeout is diabled * or not supported, this value is meaningless. * * @see #enableReceiveTimeout */ int getReceiveTimeout(); /** * Enables receive framing. * The supplied byte value in the input suggests the end of the received * frame, and read returns immediately. Only the low 8 bits of the * supplied value are significant. * * @param framingByte the frame delimiter * @throws gnu.io.UnsupportedCommOperationException * if receive framing is * not supported by the driver * @see #disableReceiveFraming */ void enableReceiveFraming(int framingByte) throws UnsupportedCommOperationException; /** * Disables receive framing. * * @see #enableReceiveFraming */ void disableReceiveFraming(); /** * @return true if receive framing is enabled. * * @see #enableReceiveFraming */ boolean isReceiveFramingEnabled(); /** * @return true if receive framing byte. If receive framing is diabled * or not supported, this value is meaningless. * * @see #enableReceiveFraming */ int getReceiveFramingByte(); /** * Sets the input buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setInputBufferSize(int size); /** * @return the input buffer size. * The driver may choose not to report correct values. */ int getInputBufferSize(); /** * Sets the output buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setOutputBufferSize(int size); /** * @return the output buffer size. * The driver may choose not to report correct values. */ int getOutputBufferSize(); } What do you think of that? Note the wishy washy nature of the spec: The driver may choose to ignore this method. Is that good enough for us? Thanks! - Doug From ra85551 at gmail.com Sun Mar 11 08:44:45 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Sun, 11 Mar 2007 17:44:45 +0300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hello, world! I am writing application that communicates with modem via AT commands. My OS is Linux Kubuntu Feisty Herd, to ensure that my application will run properly under Windows XP I installed VMWare server. When I tried to send AT command and evaluate modem answer under WinXP @ VMWare server, I actually didn't receive anything. I think that VM settings are right, because I do can communicate with modem by using standard HyperTerminall as well as I can do on native Windows. So, why RXTX doesn't work under VM, but works under Linux and pure Windows XP (i tested it there) well? The send/receive method code follows. private String sendATCommand(String command, final String waitFor, final boolean isRegex, boolean isAddCRLF, long timeout) throws BeaconConnectException { final long POLL_PERIOD = 100; final int BUFFER_SIZE = 512; final byte[] buffer = new byte[BUFFER_SIZE]; final InputStream serialInput; final OutputStream serialOutput; try { serialInput = serialPort.getInputStream(); if (command != null) { serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } } catch (IOException e) { throw new MyException("serial I/O error"); } TimerTask task = new TimerTask() { int offset = 0; int bytesRead; public synchronized void run() { try { if (serialInput.available() > 0) { bytesRead = serialInput.read(buffer, offset, BUFFER_SIZE - offset); } else { return; } } catch (IOException e) { // do nothing - maybe next time we'll read something } offset += bytesRead; if (waitFor != null) { String temporary = new String(buffer, 0, offset).trim(); if (isRegex && temporary.matches(waitFor) || temporary.contains(waitFor)) { cancel(); notify(); } } } }; Timer timer = new Timer(); timer.schedule(task, POLL_PERIOD, POLL_PERIOD); synchronized (task) { try { task.wait(timeout); task.cancel(); } catch (InterruptedException e) { } } //Cut off leading and trailing CRs, LFs and zeroes String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); System.out.println(response); return response; } -- Pavel Parkhomenko From tjarvi at qbang.org Sun Mar 11 11:48:22 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:48:22 -0600 (MDT) Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: On Sun, 11 Mar 2007, Pavel Parkhomenko wrote: > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. > > private String sendATCommand(String command, final String waitFor, > final boolean isRegex, boolean isAddCRLF, long timeout) > throws BeaconConnectException > { > final long POLL_PERIOD = 100; > final int BUFFER_SIZE = 512; > final byte[] buffer = new byte[BUFFER_SIZE]; > final InputStream serialInput; > final OutputStream serialOutput; > try > { > serialInput = serialPort.getInputStream(); > if (command != null) > { > serialOutput = serialPort.getOutputStream(); > if (isAddCRLF) > { > command += "\r\n"; > } > System.out.println(command); > serialOutput.write(command.getBytes()); > } > } > catch (IOException e) > { > throw new MyException("serial I/O error"); > } > > TimerTask task = new TimerTask() > { > int offset = 0; > int bytesRead; > public synchronized void run() > { > try > { > if (serialInput.available() > 0) > { > bytesRead = serialInput.read(buffer, offset, > BUFFER_SIZE - offset); > } > else > { > return; > } > } > catch (IOException e) > { > // do nothing - maybe next time we'll read something > } > offset += bytesRead; > if (waitFor != null) > { > String temporary = new String(buffer, 0, offset).trim(); > if (isRegex && temporary.matches(waitFor) || > temporary.contains(waitFor)) > { > cancel(); > notify(); > } > } > } > }; > > Timer timer = new Timer(); > timer.schedule(task, POLL_PERIOD, POLL_PERIOD); > synchronized (task) { > try > { > task.wait(timeout); > task.cancel(); > } > catch (InterruptedException e) > { > } > } > //Cut off leading and trailing CRs, LFs and zeroes > String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); > System.out.println(response); > return response; > } > > > Hi Pavel VMWare should not be a problem. I've used it in the past - though not with a modem. Make sure nothing else is using the modem. Then look in the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an example that should work. Note that modems could care less what OS is on top. If you are trying to match new lines to the OS and sending it to the mode for AT commands, thats probably a mistake. Also it would not hurt to print out the individual bytes that you are sending to make sure they did not get mangled along the path. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 11:55:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:55:48 -0600 (MDT) Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: On Sun, 11 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > I have been a proponent of a JSR that makes > use of RXTX. I have executed the proper agreements with Sun. > > At this point we are in the: > Early Draft Review of Draft Specifications Stage. > > The best thing to do is to enter the quiet period and create > a specification. The question of exactly how we, as a group, > want to approach this problem, remains open. > > Typically, we should have both a specification and a reference > implementation. Thus, it would be to our best advantage to have > a nice, stable, cross platform RXTX distro that adheres to the > groups specification. > > Now, from a specification standpoint, my personal view on the matter is > that we create a series of interfaces, with nice documentation (or at least > javadoc). > > Is this a good idea? Should we have a pure interface specification for > the communication API? > > There are several issues, in my mind, which still weigh on us. > Hot-pluggable dongles, long discovery process on pop-up ports, > lack of uniformity on device names, lack of uniformity on locking, > a precise understanding of how the SerialPortResourceManager > works (or even if we should have one). > > The more questions we answer in our reference implementation, the > better our specification will get. RXTX is a good working prototype, > but, I don't know if that is what we want to use for a specification. > > Here is what I have for a CommPortInterface: > */ > public interface CommPortInterface { Hi Doug, I can start going through the method interfaces later this week and giving feedback. I would suggest that the JSR should not be too generic in nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel drivers that intend to look like EIA232 ports at the kernel driver level. some ideas: EIA232PortInterface TermiosInterface SerialPortInterface Something that differentiates this from thing like USB, I2C, ... which should not have to deal with legacy serial claiming to be the comm api. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 12:52:19 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 12:52:19 -0600 (MDT) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: No news is good news with these posts. I'll start the process of pinging legal a week from Monday on my end if nobody has objections to the proposal. I just want to make sure everyone has time to raise objections. Obviously, anyone can fork from a previous version if they don't like the new license. I suspect we can avoid that though. On Sun, 4 Mar 2007, Trent Jarvi wrote: > > For those that are wondering what is going on here, this > next bit is the meat of the changes. We agreed a long time > ago to put this disclaimer in. We did a so so job. It was > in rxtx 2.0, not well written, ... So some groups using > rxtx that would like to ship rxtx so users don't need to > download, install, go to the mail-list to find why it failed, > ... Then their legal teams tell them section 5 paragraph 2 > is a show stopper. > > That was never the intent. > > > Now going through what remains... > >> and might need a (TM) suffix to make Sun happy. > > Added disclaimer at the ended 'all trademarks belong...' > >> * Line #15ff - static vs. dynamic linking - you did >> not transcribe the text from the "controlled >> interface exception" when writing this text - and >> this was good so, because these terms originally >> refer to the GPL rather than the LGPL. I think though, >> that these 4 lines are the most important ones and >> should thus be really really clear. I hope that I >> meet your original intent with the following >> suggestions: >> 1.) Instead of "A program.." it would be better to >> say "An exectuable.." in order to be closer to >> the LGPL text. > > OK. As you can see I was trying to adjust GNU text there > for the LGPL. > >> 2.) It would be better to say .. "by being dynamically >> linked with it" to clearly indicate that dynamic >> linking is meant. The matter of compilation is >> already covered by the LGPL so mentioning it again >> just leads to confusion. > > used dynamically linked terminology. > >> 3.) It would be better to say .. "is considered a >> work that uses the library in contrast to section >> 5 of the LGPL, so the terms of the LGPL do not >> apply to the resulting executable". > > I tried to address this more upfront with an intent statement. > Let me know if you have problems with it. I also tried to > make it a little more clear what was derived from the GNU > solution by moving the link location closer to GNU's suggestion. > >> >> Note that LGPL section 5 says: ..."is called a >> "work that uses the Library". Such a work, in isolation, >> is not a derivative work of the Library, and therefore >> falls outside the scope of this License." >> The next paragraph of the LGPL is exactly the problematic >> one that I hope is clarified by the exception terms you >> give. >> > > Thats the intent. Here is the combined fixes. Note that only the > material in /*-- --*/ is being touched. The new GPL license is > there but unmodified. > > > ------------------------ begin proposed new license ------------------- > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Lesser General Public > | License as published by the Free Software Foundation; either > | version 2.1 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Lesser General Public License for more details. > | > | An executable that contains no derivative of any portion of RXTX, but > | is designed to work with RXTX by being dynamically linked with it, > | is considered a "work that uses the Library" subject to the terms and > | conditions of the GNU Lesser General Public License. > | > | The following has been added to the RXTX License to remove > | any confusion about linking to RXTX. We want to allow in part what > | section 5, paragraph 2 of the LGPL does not permit in the special > | case of linking over a controlled interface. The intent is to add a > | Java Specification Request or standards body defined interface in the > | future as another exception but one is not currently available. > | > | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface > | > | As a special exception, the copyright holders of RXTX give you > | permission to link RXTX with independent modules that communicate with > | RXTX solely through the Sun Microsytems CommAPI interface version 2, > | regardless of the license terms of these independent modules, and to copy > | and distribute the resulting combined work under terms of your choice, > | provided that every copy of the combined work is accompanied by a complete > | copy of the source code of RXTX (the version of RXTX used to produce the > | combined work), being distributed under the terms of the GNU Lesser General > | Public License plus this exception. An independent module is a > | module which is not derived from or based on RXTX. > | > | Note that people who make modified versions of RXTX are not obligated > | to grant this special exception for their modified versions; it is > | their choice whether to do so. The GNU Lesser General Public License > | gives permission to release a modified version without this exception; this > | exception also makes it possible to release a modified version which > | carries forward this exception. > | > | You should have received a copy of the GNU Lesser General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > | All trademarks belong to their respective owners. > --------------------------------------------------------------------------*/ > > The original GNU Lesser General Public License Follows. > > > GNU LESSER GENERAL PUBLIC LICENSE > Version 2.1, February 1999 > > Copyright (C) 1991, 1999 Free Software Foundation, Inc. > 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > Everyone is permitted to copy and distribute verbatim copies > of this license document, but changing it is not allowed. > > [This is the first released version of the Lesser GPL. It also counts > as the successor of the GNU Library Public License, version 2, hence > the version number 2.1.] > > Preamble > > The licenses for most software are designed to take away your > freedom to share and change it. By contrast, the GNU General Public > Licenses are intended to guarantee your freedom to share and change > free software--to make sure the software is free for all its users. > > This license, the Lesser General Public License, applies to some > specially designated software packages--typically libraries--of the > Free Software Foundation and other authors who decide to use it. You > can use it too, but we suggest you first think carefully about whether > this license or the ordinary General Public License is the better > strategy to use in any particular case, based on the explanations below. > > When we speak of free software, we are referring to freedom of use, > not price. Our General Public Licenses are designed to make sure that > you have the freedom to distribute copies of free software (and charge > for this service if you wish); that you receive source code or can get > it if you want it; that you can change the software and use pieces of > it in new free programs; and that you are informed that you can do > these things. > > To protect your rights, we need to make restrictions that forbid > distributors to deny you these rights or to ask you to surrender these > rights. These restrictions translate to certain responsibilities for > you if you distribute copies of the library or if you modify it. > > For example, if you distribute copies of the library, whether gratis > or for a fee, you must give the recipients all the rights that we gave > you. You must make sure that they, too, receive or can get the source > code. If you link other code with the library, you must provide > complete object files to the recipients, so that they can relink them > with the library after making changes to the library and recompiling > it. And you must show them these terms so they know their rights. > > We protect your rights with a two-step method: (1) we copyright the > library, and (2) we offer you this license, which gives you legal > permission to copy, distribute and/or modify the library. > > To protect each distributor, we want to make it very clear that > there is no warranty for the free library. Also, if the library is > modified by someone else and passed on, the recipients should know > that what they have is not the original version, so that the original > author's reputation will not be affected by problems that might be > introduced by others. > > Finally, software patents pose a constant threat to the existence of > any free program. We wish to make sure that a company cannot > effectively restrict the users of a free program by obtaining a > restrictive license from a patent holder. Therefore, we insist that > any patent license obtained for a version of the library must be > consistent with the full freedom of use specified in this license. > > Most GNU software, including some libraries, is covered by the > ordinary GNU General Public License. This license, the GNU Lesser > General Public License, applies to certain designated libraries, and > is quite different from the ordinary General Public License. We use > this license for certain libraries in order to permit linking those > libraries into non-free programs. > > When a program is linked with a library, whether statically or using > a shared library, the combination of the two is legally speaking a > combined work, a derivative of the original library. The ordinary > General Public License therefore permits such linking only if the > entire combination fits its criteria of freedom. The Lesser General > Public License permits more lax criteria for linking other code with > the library. > > We call this license the "Lesser" General Public License because it > does Less to protect the user's freedom than the ordinary General > Public License. It also provides other free software developers Less > of an advantage over competing non-free programs. These disadvantages > are the reason we use the ordinary General Public License for many > libraries. However, the Lesser license provides advantages in certain > special circumstances. > > For example, on rare occasions, there may be a special need to > encourage the widest possible use of a certain library, so that it becomes > a de-facto standard. To achieve this, non-free programs must be > allowed to use the library. A more frequent case is that a free > library does the same job as widely used non-free libraries. In this > case, there is little to gain by limiting the free library to free > software only, so we use the Lesser General Public License. > > In other cases, permission to use a particular library in non-free > programs enables a greater number of people to use a large body of > free software. For example, permission to use the GNU C Library in > non-free programs enables many more people to use the whole GNU > operating system, as well as its variant, the GNU/Linux operating > system. > > Although the Lesser General Public License is Less protective of the > users' freedom, it does ensure that the user of a program that is > linked with the Library has the freedom and the wherewithal to run > that program using a modified version of the Library. > > The precise terms and conditions for copying, distribution and > modification follow. Pay close attention to the difference between a > "work based on the library" and a "work that uses the library". The > former contains code derived from the library, whereas the latter must > be combined with the library in order to run. > > GNU LESSER GENERAL PUBLIC LICENSE > TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION > > 0. This License Agreement applies to any software library or other > program which contains a notice placed by the copyright holder or > other authorized party saying it may be distributed under the terms of > this Lesser General Public License (also called "this License"). > Each licensee is addressed as "you". > > A "library" means a collection of software functions and/or data > prepared so as to be conveniently linked with application programs > (which use some of those functions and data) to form executables. > > The "Library", below, refers to any such software library or work > which has been distributed under these terms. A "work based on the > Library" means either the Library or any derivative work under > copyright law: that is to say, a work containing the Library or a > portion of it, either verbatim or with modifications and/or translated > straightforwardly into another language. (Hereinafter, translation is > included without limitation in the term "modification".) > > "Source code" for a work means the preferred form of the work for > making modifications to it. For a library, complete source code means > all the source code for all modules it contains, plus any associated > interface definition files, plus the scripts used to control compilation > and installation of the library. > > Activities other than copying, distribution and modification are not > covered by this License; they are outside its scope. The act of > running a program using the Library is not restricted, and output from > such a program is covered only if its contents constitute a work based > on the Library (independent of the use of the Library in a tool for > writing it). Whether that is true depends on what the Library does > and what the program that uses the Library does. > > 1. You may copy and distribute verbatim copies of the Library's > complete source code as you receive it, in any medium, provided that > you conspicuously and appropriately publish on each copy an > appropriate copyright notice and disclaimer of warranty; keep intact > all the notices that refer to this License and to the absence of any > warranty; and distribute a copy of this License along with the > Library. > > You may charge a fee for the physical act of transferring a copy, > and you may at your option offer warranty protection in exchange for a > fee. > > 2. You may modify your copy or copies of the Library or any portion > of it, thus forming a work based on the Library, and copy and > distribute such modifications or work under the terms of Section 1 > above, provided that you also meet all of these conditions: > > a) The modified work must itself be a software library. > > b) You must cause the files modified to carry prominent notices > stating that you changed the files and the date of any change. > > c) You must cause the whole of the work to be licensed at no > charge to all third parties under the terms of this License. > > d) If a facility in the modified Library refers to a function or a > table of data to be supplied by an application program that uses > the facility, other than as an argument passed when the facility > is invoked, then you must make a good faith effort to ensure that, > in the event an application does not supply such function or > table, the facility still operates, and performs whatever part of > its purpose remains meaningful. > > (For example, a function in a library to compute square roots has > a purpose that is entirely well-defined independent of the > application. Therefore, Subsection 2d requires that any > application-supplied function or table used by this function must > be optional: if the application does not supply it, the square > root function must still compute square roots.) > > These requirements apply to the modified work as a whole. If > identifiable sections of that work are not derived from the Library, > and can be reasonably considered independent and separate works in > themselves, then this License, and its terms, do not apply to those > sections when you distribute them as separate works. But when you > distribute the same sections as part of a whole which is a work based > on the Library, the distribution of the whole must be on the terms of > this License, whose permissions for other licensees extend to the > entire whole, and thus to each and every part regardless of who wrote > it. > > Thus, it is not the intent of this section to claim rights or contest > your rights to work written entirely by you; rather, the intent is to > exercise the right to control the distribution of derivative or > collective works based on the Library. > > In addition, mere aggregation of another work not based on the Library > with the Library (or with a work based on the Library) on a volume of > a storage or distribution medium does not bring the other work under > the scope of this License. > > 3. You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. To do > this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version 2, > instead of to this License. (If a newer version than version 2 of the > ordinary GNU General Public License has appeared, then you can specify > that version instead if you wish.) Do not make any other change in > these notices. > > Once this change is made in a given copy, it is irreversible for > that copy, so the ordinary GNU General Public License applies to all > subsequent copies and derivative works made from that copy. > > This option is useful when you wish to copy part of the code of > the Library into a program that is not a library. > > 4. You may copy and distribute the Library (or a portion or > derivative of it, under Section 2) in object code or executable form > under the terms of Sections 1 and 2 above provided that you accompany > it with the complete corresponding machine-readable source code, which > must be distributed under the terms of Sections 1 and 2 above on a > medium customarily used for software interchange. > > If distribution of object code is made by offering access to copy > from a designated place, then offering equivalent access to copy the > source code from the same place satisfies the requirement to > distribute the source code, even though third parties are not > compelled to copy the source along with the object code. > > 5. A program that contains no derivative of any portion of the > Library, but is designed to work with the Library by being compiled or > linked with it, is called a "work that uses the Library". Such a > work, in isolation, is not a derivative work of the Library, and > therefore falls outside the scope of this License. > > However, linking a "work that uses the Library" with the Library > creates an executable that is a derivative of the Library (because it > contains portions of the Library), rather than a "work that uses the > library". The executable is therefore covered by this License. > Section 6 states terms for distribution of such executables. > > When a "work that uses the Library" uses material from a header file > that is part of the Library, the object code for the work may be a > derivative work of the Library even though the source code is not. > Whether this is true is especially significant if the work can be > linked without the Library, or if the work is itself a library. The > threshold for this to be true is not precisely defined by law. > > If such an object file uses only numerical parameters, data > structure layouts and accessors, and small macros and small inline > functions (ten lines or less in length), then the use of the object > file is unrestricted, regardless of whether it is legally a derivative > work. (Executables containing this object code plus portions of the > Library will still fall under Section 6.) > > Otherwise, if the work is a derivative of the Library, you may > distribute the object code for the work under the terms of Section 6. > Any executables containing that work also fall under Section 6, > whether or not they are linked directly with the Library itself. > > 6. As an exception to the Sections above, you may also combine or > link a "work that uses the Library" with the Library to produce a > work containing portions of the Library, and distribute that work > under terms of your choice, provided that the terms permit > modification of the work for the customer's own use and reverse > engineering for debugging such modifications. > > You must give prominent notice with each copy of the work that the > Library is used in it and that the Library and its use are covered by > this License. You must supply a copy of this License. If the work > during execution displays copyright notices, you must include the > copyright notice for the Library among them, as well as a reference > directing the user to the copy of this License. Also, you must do one > of these things: > > a) Accompany the work with the complete corresponding > machine-readable source code for the Library including whatever > changes were used in the work (which must be distributed under > Sections 1 and 2 above); and, if the work is an executable linked > with the Library, with the complete machine-readable "work that > uses the Library", as object code and/or source code, so that the > user can modify the Library and then relink to produce a modified > executable containing the modified Library. (It is understood > that the user who changes the contents of definitions files in the > Library will not necessarily be able to recompile the application > to use the modified definitions.) > > b) Use a suitable shared library mechanism for linking with the > Library. A suitable mechanism is one that (1) uses at run time a > copy of the library already present on the user's computer system, > rather than copying library functions into the executable, and (2) > will operate properly with a modified version of the library, if > the user installs one, as long as the modified version is > interface-compatible with the version that the work was made with. > > c) Accompany the work with a written offer, valid for at > least three years, to give the same user the materials > specified in Subsection 6a, above, for a charge no more > than the cost of performing this distribution. > > d) If distribution of the work is made by offering access to copy > from a designated place, offer equivalent access to copy the above > specified materials from the same place. > > e) Verify that the user has already received a copy of these > materials or that you have already sent this user a copy. > > For an executable, the required form of the "work that uses the > Library" must include any data and utility programs needed for > reproducing the executable from it. However, as a special exception, > the materials to be distributed need not include anything that is > normally distributed (in either source or binary form) with the major > components (compiler, kernel, and so on) of the operating system on > which the executable runs, unless that component itself accompanies > the executable. > > It may happen that this requirement contradicts the license > restrictions of other proprietary libraries that do not normally > accompany the operating system. Such a contradiction means you cannot > use both them and the Library together in an executable that you > distribute. > > 7. You may place library facilities that are a work based on the > Library side-by-side in a single library together with other library > facilities not covered by this License, and distribute such a combined > library, provided that the separate distribution of the work based on > the Library and of the other library facilities is otherwise > permitted, and provided that you do these two things: > > a) Accompany the combined library with a copy of the same work > based on the Library, uncombined with any other library > facilities. This must be distributed under the terms of the > Sections above. > > b) Give prominent notice with the combined library of the fact > that part of it is a work based on the Library, and explaining > where to find the accompanying uncombined form of the same work. > > 8. You may not copy, modify, sublicense, link with, or distribute > the Library except as expressly provided under this License. Any > attempt otherwise to copy, modify, sublicense, link with, or > distribute the Library is void, and will automatically terminate your > rights under this License. However, parties who have received copies, > or rights, from you under this License will not have their licenses > terminated so long as such parties remain in full compliance. > > 9. You are not required to accept this License, since you have not > signed it. However, nothing else grants you permission to modify or > distribute the Library or its derivative works. These actions are > prohibited by law if you do not accept this License. Therefore, by > modifying or distributing the Library (or any work based on the > Library), you indicate your acceptance of this License to do so, and > all its terms and conditions for copying, distributing or modifying > the Library or works based on it. > > 10. Each time you redistribute the Library (or any work based on the > Library), the recipient automatically receives a license from the > original licensor to copy, distribute, link with or modify the Library > subject to these terms and conditions. You may not impose any further > restrictions on the recipients' exercise of the rights granted herein. > You are not responsible for enforcing compliance by third parties with > this License. > > 11. If, as a consequence of a court judgment or allegation of patent > infringement or for any other reason (not limited to patent issues), > conditions are imposed on you (whether by court order, agreement or > otherwise) that contradict the conditions of this License, they do not > excuse you from the conditions of this License. If you cannot > distribute so as to satisfy simultaneously your obligations under this > License and any other pertinent obligations, then as a consequence you > may not distribute the Library at all. For example, if a patent > license would not permit royalty-free redistribution of the Library by > all those who receive copies directly or indirectly through you, then > the only way you could satisfy both it and this License would be to > refrain entirely from distribution of the Library. > > If any portion of this section is held invalid or unenforceable under any > particular circumstance, the balance of the section is intended to apply, > and the section as a whole is intended to apply in other circumstances. > > It is not the purpose of this section to induce you to infringe any > patents or other property right claims or to contest validity of any > such claims; this section has the sole purpose of protecting the > integrity of the free software distribution system which is > implemented by public license practices. Many people have made > generous contributions to the wide range of software distributed > through that system in reliance on consistent application of that > system; it is up to the author/donor to decide if he or she is willing > to distribute software through any other system and a licensee cannot > impose that choice. > > This section is intended to make thoroughly clear what is believed to > be a consequence of the rest of this License. > > 12. If the distribution and/or use of the Library is restricted in > certain countries either by patents or by copyrighted interfaces, the > original copyright holder who places the Library under this License may add > an explicit geographical distribution limitation excluding those countries, > so that distribution is permitted only in or among countries not thus > excluded. In such case, this License incorporates the limitation as if > written in the body of this License. > > 13. The Free Software Foundation may publish revised and/or new > versions of the Lesser General Public License from time to time. > Such new versions will be similar in spirit to the present version, > but may differ in detail to address new problems or concerns. > > Each version is given a distinguishing version number. If the Library > specifies a version number of this License which applies to it and > "any later version", you have the option of following the terms and > conditions either of that version or of any later version published by > the Free Software Foundation. If the Library does not specify a > license version number, you may choose any version ever published by > the Free Software Foundation. > > 14. If you wish to incorporate parts of the Library into other free > programs whose distribution conditions are incompatible with these, > write to the author to ask for permission. For software which is > copyrighted by the Free Software Foundation, write to the Free > Software Foundation; we sometimes make exceptions for this. Our > decision will be guided by the two goals of preserving the free status > of all derivatives of our free software and of promoting the sharing > and reuse of software generally. > > NO WARRANTY > > 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO > WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. > EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR > OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY > KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE > IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE > LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME > THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. > > 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN > WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY > AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU > FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR > CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE > LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING > RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A > FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF > SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH > DAMAGES. > > END OF TERMS AND CONDITIONS > > How to Apply These Terms to Your New Libraries > > If you develop a new library, and you want it to be of the greatest > possible use to the public, we recommend making it free software that > everyone can redistribute and change. You can do so by permitting > redistribution under these terms (or, alternatively, under the terms of the > ordinary General Public License). > > To apply these terms, attach the following notices to the library. It is > safest to attach them to the start of each source file to most effectively > convey the exclusion of warranty; and each file should have at least the > "copyright" line and a pointer to where the full notice is found. > > > Copyright (C) > > This library is free software; you can redistribute it and/or > modify it under the terms of the GNU Lesser General Public > License as published by the Free Software Foundation; either > version 2.1 of the License, or (at your option) any later version. > > This library is distributed in the hope that it will be useful, > but WITHOUT ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > Lesser General Public License for more details. > > You should have received a copy of the GNU Lesser General Public > License along with this library; if not, write to the Free Software > Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > > Also add information on how to contact you by electronic and paper mail. > > You should also get your employer (if you work as a programmer) or your > school, if any, to sign a "copyright disclaimer" for the library, if > necessary. Here is a sample; alter the names: > > Yoyodyne, Inc., hereby disclaims all copyright interest in the > library `Frob' (a library for tweaking knobs) written by James Random Hacker. > > , 1 April 1990 > Ty Coon, President of Vice > > That's all there is to it! > ------------------------ end of proposed license ------------------ > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From gjhanna at gmail.com Sun Mar 11 14:21:17 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Mon, 12 Mar 2007 09:21:17 +1300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hi Pavel, We are using RXTX under VMWare server in production, quite satisfactorily. We're using Red Hat Enterprise Server 4, and ... Whatever the "enterprise" VMWare product is. Regards, Greg H > Subject: [Rxtx] RXTX under VMWare server > To: rxtx at qbang.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. [ ... snip ... ] -- Pavel Parkhomenko -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070311/4cebb6f9/attachment-0078.html From gergg at cox.net Sun Mar 11 23:39:19 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 12 Mar 2007 00:39:19 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: <45F4E787.6050502@cox.net> Trent Jarvi wrote: > I can start going through the method interfaces later this week and giving > feedback. I would suggest that the JSR should not be too generic in > nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel > drivers that intend to look like EIA232 ports at the kernel driver level. > > some ideas: > > EIA232PortInterface > TermiosInterface > SerialPortInterface > > Something that differentiates this from thing like USB, I2C, ... which > should not have to deal with legacy serial claiming to be the comm api. I'm going to throw out a suggestion, which I am mostly serious about. What would happen if we took the appropriate bits of the J2ME connector API, and just used that as the new COMM API so that finally JSE and JME had a common foundation for these kinds of things? Gregg Wonderly From ra85551 at gmail.com Mon Mar 12 09:08:37 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Mon, 12 Mar 2007 18:08:37 +0300 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Should any application use the modem, HyperTerminal won't be able to talk to the modem. But it actually can send and receive AT comands, while my application cannot :-( > Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Thansk for the reference. I examined that example and found that there's no significant differences between my read/write implementation and that one, except that SimpleSnuV1 listens for serialEvent's, but not for sake of data retrieval, just for printing them out - I don't know why ;-) > Note that modems could care less what OS is on top. If you are trying to > match new lines to the OS and sending it to the mode for AT commands, > thats probably a mistake. I do send strings to serial port, not to OS, and do try to get answers back. If it is the mistake, what's the right way? > Also it would not hurt to print out the > individual bytes that you are sending to make sure they did not get > mangled along the path. Yeah, I am printing these bytes before doing write, but it means that I only see what I intend to write. How can I ensure that these bytes have gone out of the box and reached my modem? BTW, I found that my send/receive method is complex enough, so I've rewritten it. Please, see the following code and point any mistakes, because I don't know where can they remain yet. private static final int LARGE_TIMEOUT = 15000; private static final int SMALL_TIMEOUT = 500; ... private String sendATCommand(String command, String waitFor, boolean isRegex, boolean isAddCRLF) throws BeaconConnectException { byte[] buffer = new byte[512]; int offset; String result = ""; try { if (waitFor != null) { serialPort.enableReceiveTimeout(LARGE_TIMEOUT); } else { serialPort.enableReceiveTimeout(SMALL_TIMEOUT); } if (command != null) { OutputStream serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } offset = 0; InputStream serialInput = serialPort.getInputStream(); while (serialInput.available() != -1) { int bytesRead = serialInput.read(buffer, offset, buffer.length - offset); if (bytesRead == 0) { break; } offset += bytesRead; result = new String(buffer, 0, offset).trim(); if (waitFor != null) { System.out.println(result); if (isRegex && result.matches(waitFor) || result.contains(waitFor)) { break; } } } } catch (UnsupportedCommOperationException e) { throw new MyException("unsupported operation"); } catch (IOException e) { throw new MytException("serial I/O error"); } return result; } -- Pavel Parkhomenko From clayno at hotpop.com Thu Mar 15 02:47:34 2007 From: clayno at hotpop.com (Christopher Layno) Date: Thu, 15 Mar 2007 16:47:34 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi, we're using the latest release of rxtx (2.1-7r2) for our system that has two applications using the library. one application sends requests to the modem while the other simply checks the modem status. we deployed our system on a pentium machine with red hat linux 9.0 installed. now the problem arises when these two applications try to access the same modem at the same time. one of them will eventually have to throw the PortInUseException as shown below: 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException gnu.io.PortInUseException: root PID = 743 Program = java root PID = 743 Program = java root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) this was expected. what we didn't expect though was that if we repeat the scenario 5 times, always 5 times, the application would also throw a VM error: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4473CD21 Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so Current Java thread: at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) - locked <0x44cfd4c8> (a gnu.io.CommPortIdentifier) at ************ at ************ - locked <0x4476a468> (a **********) at ************ at ************ at ************ at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java :261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages( TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run( TCPTransport.java:701) at java.lang.Thread.run(Thread.java:534) note: i replaced some sensitive data with asterisks our team has looked everywhere on the internet, including your mail archives, for a solution to this problem but to no avail. i really hope you could help us out on this one. thanks in advance! best regards, chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070315/1936460a/attachment-0075.html From tjarvi at qbang.org Fri Mar 16 04:30:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 04:30:25 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: On Thu, 15 Mar 2007, Christopher Layno wrote: > hi, > > we're using the latest release of rxtx (2.1-7r2) for our system that has two > applications using the library. one application sends requests to the modem > while the other simply checks the modem status. we deployed our system on a > pentium machine with red hat linux 9.0 installed. > > now the problem arises when these two applications try to access the same > modem at the same time. one of them will eventually have to throw the > PortInUseException as shown below: > > 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException > gnu.io.PortInUseException: root PID = 743 Program = java root PID = > 743 Program = java root PID = 743 Program = ??? root PID = 743 Program > = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root > PID = 743 Program = ??? root PID = 743 Program = ??? > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > > this was expected. what we didn't expect though was that if we repeat the > scenario 5 times, always 5 times, the application would also throw a VM > error: > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x4473CD21 > Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 > Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so > > Current Java thread: > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) Hi Chris The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. The code is originally by Werner Almesberger. He gave us permission to use it in rxtx. You might look at what has changed since 1998 in his fuser application. Or you can just do like other OSs and do the following in fuserImp.c JNIEXPORT jstring JNICALL Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv *env, jobject obj, jstring arg) { return (*env)->NewStringUTF(env, "Unknown Application"); } It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. -- Trent Jarvi tjarvi at qang.org From Adrien.TOS at ingenico.com Fri Mar 16 05:11:12 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Fri, 16 Mar 2007 12:11:12 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903CBC312@frsnprexc1.usr.ingenico.loc> Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070316/972ab214/attachment-0074.html From joachim at buechse.de Fri Mar 16 05:13:24 2007 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 16 Mar 2007 12:13:24 +0100 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. From tjarvi at qbang.org Fri Mar 16 16:36:29 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 16:36:29 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Fri Mar 16 16:02:23 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 16 Mar 2007 18:02:23 -0400 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Not all platforms are Unix based. Also mixing native library usage and command-line calls is not an elegant solution, IMHO. One or the other, but not both. Andre On 16-Mar-07, at 07:13 , Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is > trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We >> only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From clayno at hotpop.com Sun Mar 18 22:17:28 2007 From: clayno at hotpop.com (Christopher Layno) Date: Mon, 19 Mar 2007 12:17:28 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi everyone, thank you so much for your replies. they were really helpful. anyway, before i sent the email, my team was already implementing a temporary solution by using joachim's suggestion. we invoked a lsof command from our java code although i share the same concern with trent and andre-john about portability issues. that's why i said it's just temporary. my superiors have yet to approve our bug fix. so my question now is this: is recompiling the rxtx source code the only way to solve this problem? because if it's the only solution, then i think my superiors would rather have a new release from the rxtx community itself that fixes this bug(?) rather than have my team recompile the source code. best regards, chris Trent Jarvi wrote: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. ... It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070318/237463b2/attachment-0071.html From tjarvi at qbang.org Mon Mar 19 16:20:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Mar 2007 16:20:52 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: Hi Chris I can compile a new version after the 21st if you do not feel comfortable doing so. Please send me an email reminder off-line then. On Mon, 19 Mar 2007, Christopher Layno wrote: > hi everyone, > > thank you so much for your replies. they were really helpful. > > anyway, before i sent the email, my team was already implementing a > temporary solution by using joachim's suggestion. > we invoked a lsof command from our java code although i share the same > concern with trent and andre-john about > portability issues. that's why i said it's just temporary. my superiors have > yet to approve our bug fix. > > so my question now is this: is recompiling the rxtx source code the only way > to solve this problem? because if it's the only > solution, then i think my superiors would rather have a new release from the > rxtx community itself that fixes this bug(?) > rather than have my team recompile the source code. > > best regards, > > chris > > Trent Jarvi wrote: > > Hi Joachim > > It would be nice to have that functionality but calling the program > introduces too many issues imho. Explaining to someone why rxtx invoked a > rogue lsof does not sound very interesting. > > On Fri, 16 Mar 2007, Joachim Buechse wrote: > > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: > > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. > > _______________________________________________ > Rxtx mailing list > Rxtx 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 Eric.Arseneau at sun.com Tue Mar 20 11:47:33 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Tue, 20 Mar 2007 10:47:33 -0700 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 Message-ID: <46001E35.9040608@sun.com> Anyone have any experience with RXTX working with JDK 6 on other platforms ? From mm at UDel.Edu Tue Mar 20 12:18:29 2007 From: mm at UDel.Edu (Mike Markowski) Date: Tue, 20 Mar 2007 14:18:29 -0400 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 In-Reply-To: <46001E35.9040608@sun.com> References: <46001E35.9040608@sun.com> Message-ID: <46002575.4000306@udel.edu> Eric Arseneau wrote: > Anyone have any experience with RXTX working with JDK 6 on other platforms ? I'm using 32 bit intel, gentoo linux, jdk6 with no problems. My applications only use a serial port, though, nothing on the parallel port. Mike From falko.guderian at gmx.de Wed Mar 21 08:17:35 2007 From: falko.guderian at gmx.de (Falko Guderian) Date: Wed, 21 Mar 2007 15:17:35 +0100 Subject: [Rxtx] RXTX binaries for SH4 Message-ID: <46013E7F.40102@gmx.de> Dear developers, I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no possiblities to compile the source code. Better, I'm not able to do this at the moment. Can you provide me with rxtxSerial.dll (SH4) in the rxtx-2.1-8-testing version? (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) The reason for the testing version is I need custom baud rates. Thanks for help. Kind regards, Falko Guderian From tjarvi at qbang.org Wed Mar 21 21:38:37 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Mar 2007 21:38:37 -0600 (MDT) Subject: [Rxtx] RXTX binaries for SH4 In-Reply-To: <46013E7F.40102@gmx.de> References: <46013E7F.40102@gmx.de> Message-ID: On Wed, 21 Mar 2007, Falko Guderian wrote: > Dear developers, > > I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no > possiblities to compile the source code. Better, I'm not able to do this > at the moment. Can you provide me with rxtxSerial.dll (SH4) in the > rxtx-2.1-8-testing version? > (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) > > The reason for the testing version is I need custom baud rates. > > Thanks for help. > Hi Falko WinCE binary format is not supported by gcc. That makes compiling limited to those familiar with the WinCE tools. I hope someone is able to provide them for you but it is not likely. WinCE has been compiled by others in the past but rxtx.org builds have never included WinCE. There is some information with the source concerning WinCE builds if you decide to do it. We can share your results too if you like. The source in the WinCE has never been updated for the custom baud rate. That would need changes from the main source I presume. If you look at the source, you will note that Michal Hobot created a mini fork in the source to handle wince but it has not been updated for 3 years. -- Trent Jarvi tjarvi at qbang.org From Adrien.TOS at ingenico.com Thu Mar 22 07:08:55 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Thu, 22 Mar 2007 14:08:55 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Hi everybody, Do you have any comments on this issue? Thanks! AT ________________________________ De : Adrien TOS Envoy? : vendredi 16 mars 2007 12:11 ? : 'rxtx at qbang.org' Cc : Adrien TOS Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070322/2306c538/attachment-0067.html From jeremy.reeve at zen.co.uk Mon Mar 19 07:36:04 2007 From: jeremy.reeve at zen.co.uk (Jeremy S. Reeve) Date: Mon, 19 Mar 2007 13:36:04 +0000 Subject: [Rxtx] rxtx failing to compile on Fedora Core 6 Message-ID: <1174311364.21865.6.camel@d9thc> When trying to compile latest source : rxtx-2.1-7r2 I get the following when running configure: ---------------- checking os.version 2.6.18-1.2200.fc5smp WARNING: configure is having a hard time determining which directory contains the file jni_md.h. Edit Makefile and fix the variable JAVANATINC to point to the correct directory. The following options are available: /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/ /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/linux/ If there are more than one option available the first was selected. WARNING: Kernel include files do not match the current kernel configure: creating ./config.status ------------------------ which seems OK checking the resultant Makefile but when attempting to build with gmake install I get the following output : ---------------------- 34 problems (34 warnings)/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/javah -classpath .:/home/jsr/rxtxsrc/rxtx-2.1-7r2:/home/jsr/rxtxsrc/rxtx-2.1-7r2/src:/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/ext/RXTXcomm.jar -d i686-pc-linux-gnu -jni `(for i in CommDriver CommPortEnumerator CommPortIdentifier CommPort CommPortOwnershipListener Configure I2C I2CPortEvent I2CPortEventListener I2CPort LPRPort NoSuchPortException ParallelPortEvent ParallelPortEventListener ParallelPort PortInUseException Raw RawPortEvent RawPortEventListener RawPort RS485 RS485PortEvent RS485PortEventListener RS485Port RXTXCommDriver RXTXPort RXTXVersion SerialPortEvent SerialPortEventListener SerialPort UnsupportedCommOperationException UnSupportedLoggerException Zystem;do \ if grep > /dev/null native.* \( /home/jsr/rxtxsrc/rxtx-2.1-7r2/./src/$i.java; then \ echo gnu.io.$i; \ fi; \ done)` i686-pc-linux-gnu/gnu_io_CommPortIdentifier.h: No such file or directory make: *** [/home/jsr/rxtxsrc/rxtx-2.1-7r2/gnu/io/CommDriver.class] Error 1 ------------------------ Any ideas or pointers? Regards, Jeremy From tjarvi at qbang.org Sat Mar 24 08:12:54 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 Mar 2007 08:12:54 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > From Adrien.TOS at ingenico.com Sat Mar 24 11:53:22 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Sat, 24 Mar 2007 18:53:22 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> I do not have the threshold setting enabled, I have explicitely disabled it with: port_.disableReceiveThreshold(); I have also run the same tests with the threshold setting enabled, but they also fail in the same way as described below. So it seems there is a problem with timeout handling on Win32? ________________________________ From: rxtx-bounces at qbang.org on behalf of Trent Jarvi Sent: Sat 3/24/2007 3:12 PM To: RXTX Developers and Users Subject: Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 8312 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20070324/f9e39c9b/attachment-0065.bin From greg.johnson at manchester.ac.uk Sun Mar 25 13:41:36 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Sun, 25 Mar 2007 21:41:36 +0200 Subject: [Rxtx] Mac intel weirdness Message-ID: Hi folks, I'm trying to get rxtx to work on my macbook pro with a USB-serial dongle on it. I am using the 2.1-8 code from the CVS (though it seems to report itself as 2.1-7: makes it difficult to prove to oneself that the changes have 'taken'! - line 4210 in SerialImp.c, line 40 in RXTXVersion.java) I am trying the 2.1-8 because of horrible lock problems in 2.1-7. However, the serialport closure code seems to be broken - it won't close because it believes the (previously opened!) port doesn't exist. Here is what I'm trying: 0. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "false" 1. Open a port Serialport serialport = (SerialPort) commportidentifier.open ("test",100); 2. Talk to a device ... 3. Close port serialport.close(); 4. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "true" - why is this? 5. Try to reopen port Serialport serialport2 = (SerialPort) commportidentifier.open("test", 100); throws PortInUseException. I've dug around a bit in the source, and it seems the SerialPort.close () should call the CommPortIdentifier.internalClosePort() (line 67 of CommPort.java). However, I crash out with the NoSuchPortException when getPortIdentifier is called. Which seems quite weird to me, seeing as it is called on this - which was create just beforehand. Does anyone know how to fix this? Cheers, greg From knute at frazmtn.com Sat Mar 24 10:32:38 2007 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 24 Mar 2007 09:32:38 -0700 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc>, Message-ID: <4604F036.17833.135298@knute.frazmtn.com> > >The behavior of timeout depends upon the setting of the threshold. Do you >have the threshold setting? > This is the same bug I reported last fall. There was a fellow that sent me an email asking if it had been fixed. I told him I didn't think so. He got somebody to write a fix for him but I have not been able to contact him again for the actual changes. The inaccurate timeout and the failure of blocking when no timeouts are set is a serious bug in my humble opinion and renders the software unusable for my applications. I'd really like to have an alternative to the Sun comm api but there just isn't one that I know of. -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Mar 26 16:17:00 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 26 Mar 2007 16:17:00 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> Message-ID: >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. From ra85551 at gmail.com Tue Mar 27 10:18:36 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Tue, 27 Mar 2007 20:18:36 +0400 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Ultimately I found a solution. At first, that wasn't actually the VMWare + WinXP + RXTX issue, that was WinXP + RXTX issue. But on pure XP it sometimes workes, sometimes not, while under VMWare I had never seen my snippet working at all. SimpleSnuV1.java would not help me, because there is only one line I missed, and SimpleSnuV1.java also doesn't contain it! It is as follows: serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_OUT | SerialPort.FLOWCONTROL_RTSCTS_IN); Thank you for your attention. -- Pavel Parkhomenko From griff at op.pl Wed Mar 28 01:28:19 2007 From: griff at op.pl (griff@op.pl) Date: Wed, 28 Mar 2007 09:28:19 +0200 Subject: [Rxtx] No blocking read on Windows. Message-ID: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/5d07d571/attachment-0062.html -------------- next part -------------- Hi, I have problem that InputStram.read() (SerialPort)?returns -1 instead blocking and waiting for data. I found that this problem was ?known in 2005 : ? >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > >> Hi Trent >> >> Thanks for the fast response. >> Here's a Q&D test program for the blocking read on windows that just >> attempts to read one byte, and prints the resulting byte. On my system it >> returns -1, where I expect that it keeps waiting for data. >> >This isn't happening on Linux so the bug is in src/termios.c.? I'll have >something this weekend to fix that. I'm using RXTX 2.1.7r2 and the problem still is here. Im using Windows XP and java 1.5 disableReciveTimeout() and disableReciveTreshhold() dont help. ? best regards ? Piotr Zielniok From Adrien.TOS at ingenico.com Wed Mar 28 01:40:46 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Wed, 28 Mar 2007 09:40:46 +0200 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903E88880@frsnprexc1.usr.ingenico.loc> Looking at the code, it seems there is no support for infinite timeout? And maybe the count++ < 20 condition is breaking out of the loop too early? The only condition to break out of the loop should either be the timeout has expired or the number of requested bytes has been received. -----Message d'origine----- De : rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] De la part de Trent Jarvi Envoy? : mardi 27 mars 2007 00:17 ? : RXTX Developers and Users Objet : Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From j.kenneth.gentle at acm.org Wed Mar 28 06:44:15 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 28 Mar 2007 08:44:15 -0400 Subject: [Rxtx] No blocking read on Windows. In-Reply-To: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> References: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> Message-ID: <200703281844.l2SIiITW028614@qbang.org> Just another "ME TOO!" - I'm seeing this problem on Windows XP, jre for windows XP/Embedded. I cranked receiveTimeout up to Integer.MAX_INT, but it doesn't seem to wait that long At 03:28 2007-03-28, you wrote: >Hi, >I have problem that InputStram.read() (SerialPort) returns -1 >instead blocking and waiting for data. I found that this problem >was known in 2005 : > > >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > > > >> Hi Trent > >> > >> Thanks for the fast response. > >> Here's a Q&D test program for the blocking read on windows that just > >> attempts to read one byte, and prints the resulting byte. On my system it > >> returns -1, where I expect that it keeps waiting for data. > >> > > >This isn't happening on Linux so the bug is in src/termios.c. I'll have > >something this weekend to fix that. > >I'm using RXTX 2.1.7r2 and the problem still is here. >Im using Windows XP and java 1.5 >disableReciveTimeout() and disableReciveTreshhold() dont help. > >best regards > >Piotr Zielniok > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From greg.johnson at manchester.ac.uk Wed Mar 28 14:43:29 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Wed, 28 Mar 2007 22:43:29 +0200 Subject: [Rxtx] Cannot close and reopen serial port Message-ID: <377F9765-7A9D-4CE9-9176-FFB63A2594F0@manchester.ac.uk> Dear all, It appears I cannot close a port properly: SerialPort serialport = portid.open("myprog",100); // do some stuff, all works fine serialport.close(); // all seems fine but... SerialPort sp2 = portid.open("myprog",100); throws PortInUseException. And when I dig into the rxtx code, I find in CommPort.java, in close(): CommPortIdentifier cp = CommPortIdentifier.getPortIdentifier(this); (line 64 or there abouts) but this throws a NoSuchPortException which is caught but ignored (line 74ish). Can anyone suggest how this could happen: a port that was valid, opened, and used, throws a NSPE when it comes to closing it? I'm pulling my (remaining) hair out over this one! Cheers, greg PS And thanks for RXTX - it's great to have! PPS (21.-7. winxp/osx both, java 1.5) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/c28852fc/attachment-0061.html From rxtx at vrijheidslaan.net Fri Mar 30 16:52:50 2007 From: rxtx at vrijheidslaan.net (Rob) Date: Fri, 30 Mar 2007 22:52:50 -0000 Subject: [Rxtx] Cvs Question Message-ID: <61896.80.126.150.87.1175295162.squirrel@webmail.provalue.nl> Hi There, Im trying to get the latest version to work on mac osx. Problem is that i can't checkout version 2.1.8. Probably my fault but can some one please give me the alternative commands for: [user at myhost]$ export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot [user at myhost]$ cvs login Thanx, Rob From ra85551 at gmail.com Thu Mar 1 03:47:06 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Thu, 1 Mar 2007 13:47:06 +0300 Subject: [Rxtx] enableReceiveTimeout() issue Message-ID: Hello, world! I found a limitation of 16300 ms for CommPort's enableReceiveTimeout() method, while in original javax.comm docs there are no any references to that. Is that a bug or feature? I actually need longer timeouts sometimees. -- Pavel Parkhomenko From lyon at docjava.com Thu Mar 1 07:54:17 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 01 Mar 2007 09:54:17 -0500 Subject: [Rxtx] parametric singleton design pattern In-Reply-To: References: <22d55aea0702081207q5e7f6785l352d498d6f5f9fb1@mail.gmail.com> <22d55aea0702100034o3bcf42f3j1d1a6257029a67b0@mail.gmail.com> Message-ID: Hi All, I have been thinking about the use of a design pattern to cache resources that are consumed by processes. Toward that end, I have arrived at a parametric singleton design pattern, which I mentioned on this list some time ago. The idea has been published at: http://www.jot.fm/issues/issue_2007_03/column2 I can't help but think that there should be an API available for dealing with the tracking of serial port usage. Perhaps it is a kind of resource manager called the: SerialPortManager basic prototypes already exist in this vain. See, for example: http://www.ce.rit.edu/research/projects/2005_fall/rt_poolsystem/doc/PoolMon/SerialPortManager.html http://www.eventhelix.com/RealtimeMantra/PatternCatalog/serial_port_design_pattern.htm And others shown by a google search on "SerialPortManager" Cheers! - Doug From Eric.Arseneau at sun.com Thu Mar 1 10:15:03 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:15:03 -0800 Subject: [Rxtx] Any known Java 6 issues with RXTX 2.1-7r2 ? Message-ID: <45E70A17.1060206@sun.com> I just did a test on a recent build of Solaris 11 x86 and it seems that I can connect to my serial device fine when Java 5 is the default, but when Java 6 is the default, no go. Any information ? From Eric.Arseneau at sun.com Thu Mar 1 10:19:58 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:19:58 -0800 Subject: [Rxtx] Mac OS X and missing data Message-ID: <45E70B3E.7040908@sun.com> We have a device which is USB based but presents itself as a serial port to a machine. On my MacBook Pro I can get excellent throughput if I get my device to send data as quickly as possible. On the desktop side, if I do an type of disk IO to log the data I get, I end up with some missing data at some point. I hooked up a USB analyzer and did confirm that all the data is sent as expected to the desktop from the device. I found a work around for this, buffer the data in memory and only write the data out when I've received it all. However, when the same code and same device is attempted on a co-workers MacBook Pro (same hardware specs), I get errors and must slow down dramatically the device side's sending of data. Any ideas/recommendations on what I can do to get rid of this error ? From what I can tell, it seems that RXTX is not able to wake up to the interrupts coming in indicating data is ready, quickly enough, is there anything I can do ? From chinkaiw at hotmail.com Fri Mar 2 00:57:43 2007 From: chinkaiw at hotmail.com (Wang Chinkai) Date: Fri, 02 Mar 2007 07:57:43 +0000 Subject: [Rxtx] dynamic detect rs232 port Message-ID: Hi all I have a question about detecting rs232 port dynamicly. I have to aceess some port and detect rs232 port at the same time. Some usb device simulates rs232 port , and I can not know what the port name it gets until it connects,so I have to detect it dynamic,but I have to access another rs232 device at the same time. I found a problem. If I use CommPortIdentifier.getPortIdentifiers() to get new port list , and the other rs232 access function will not close port correctly. So , How can I solve it . Thanks. _________________________________________________________________ ?? 2GB ???? Windows Live Mail ????????????? http://ideas.live.com/programpage.aspx?versionid=5d21c51a-b161-4314-9b0e-4911fb2b2e6d From eu259473 at tele2.it Fri Mar 2 06:16:40 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 02 Mar 2007 14:16:40 +0100 Subject: [Rxtx] rxtx on HP tru 64 unix Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070302/706c7a70/attachment-0089.html From tjarvi at qbang.org Fri Mar 2 08:39:33 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 08:39:33 -0700 (MST) Subject: [Rxtx] rxtx on HP tru 64 unix In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, "Giuseppe Marchese" wrote: > Hi > > I try to install rxtx on hp tru 64 but make fails, > There are somebody that do the same and work. > > > Sorry for may english! > > Hi Giuseppe Could you provide a log of the failure? script ./configure make # use gnu make exit The information will be in the typescript created. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 2 19:56:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 19:56:52 -0700 (MST) Subject: [Rxtx] dynamic detect rs232 port In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, Wang Chinkai wrote: > Hi all > > I have a question about detecting rs232 port dynamicly. > > I have to aceess some port and detect rs232 port at the same time. > Some usb device simulates rs232 port , and I can not know > what the port name it gets until it connects,so I have to detect it > dynamic,but I have to access > another rs232 device at the same time. > > I found a problem. Hi Wang This is a known problem. The code is braindead there. In fact there needs to be events even in a rudamentary way when you add a usb dongle. I'm burried in tasks not far from rxtx but not in rxtx. I can't get to the problem but we would accept patches if you dig into it. [I'm getting to the license question earlier too; I don't have another 10%] -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Fri Mar 2 23:19:01 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 01:19:01 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Hi, Under ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable USB -> serial converter(using virtual com port drivers), with using example code pretty much straight out of http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port opens fine, enumerations all work, etc. My application calls for a large amount of data to be transferred in a short amount of time at 2,000,000 baud. My hardware sends approximately 15,232 bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL converter work fine, and the application works using C++. In C++, I do a hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); to open the port, and a boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); to read the port. The variable buffer fills with the 15238 bytes, and returns. If I do a resultz = is.read(cbuf,0,15238); in java with RXTX where is = new BufferedReader(new InputStreamReader(port.getInputStream())); and where resultz is an int, and cbuf is a char [] cbuf, resultz gets EXACTLY 3968 bytes the first time called. If I call it multiple times, I get roughly 11k total(less than what is sent), never more than the 3968 bytes per is.read() call. My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 bytes. I've played with inputbuffersize, receive threshold, receivetimeout, and so on. The FTDI virtual com port drivers that I'm using are rock solid, and have had zero problems with them using a variety of applications, some of my own, some professionally written, etc. No flow control is used anyplace, no RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. No exceptions are being thrown. What am I doing wrong, and what I can adjust to receive the full 15k bytes in one single read? Thanks! Keith From Eric.Arseneau at sun.com Fri Mar 2 23:32:07 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Fri, 02 Mar 2007 22:32:07 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <45E91667.20501@sun.com> This is the same type of thing that is happening to me on Mac OS X and does not seem to behave the same on different machines. I posted a day or two ago on this with subject "Mac OS X and missing data". Would love to hear if there is a solution to this :) From tjarvi at qbang.org Sat Mar 3 10:54:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 10:54:17 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > Hi, > > Under > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable > USB -> serial converter(using virtual com port drivers), with using example > code pretty much straight out of > http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port > opens fine, enumerations all work, etc. > > My application calls for a large amount of data to be transferred in a short > amount of time at 2,000,000 baud. My hardware sends approximately 15,232 > bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL > converter work fine, and the application works using C++. > > In C++, I do a > > hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, > OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); > > to open the port, and a > > boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); > > to read the port. > > The variable buffer fills with the 15238 bytes, and returns. > > If I do a > > resultz = is.read(cbuf,0,15238); in java with RXTX > > where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > > and where resultz is an int, and cbuf is a char [] cbuf, resultz gets > EXACTLY 3968 bytes the first time called. If I call it multiple times, I get > roughly 11k total(less than what is sent), never more than the 3968 bytes > per is.read() call. > > My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 > bytes. > > I've played with inputbuffersize, receive threshold, receivetimeout, and so > on. The FTDI virtual com port drivers that I'm using are rock solid, and > have had zero problems with them using a variety of applications, some of my > own, some professionally written, etc. No flow control is used anyplace, no > RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. > > No exceptions are being thrown. > > What am I doing wrong, and what I can adjust to receive the full 15k bytes > in one single read? > > Thanks! > Hi Keith I would expect a 20 meg application is going to have different behavior with the OS than a smaller application with respect to the kernel memory managment, schedualing, ... Something subtle could be causing problems. With respect to the recieve timeout and threshold, if you set the timeout to zero and the threshold to the size of data you expect, read should not return until it get that data. You may try with a stand alone application that tests just that with the C/C++ API. If the read is returning with less data when tested for short reads, you have found a bug in the device driver more than likely. The USB dongle vendor would probably be interested in knowing about this. As mentioned, these devices are getting very good; almost bug free. I suspect you found a bug though if you did use the threshold and timeout properly. The missing data is typical when not using flow control. When the OS buffering fills, the hardware will start dropping bytes. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:38:52 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:38:52 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> update: I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now instead of 3968. This makes sense. 128 bytes of overhead + 3968 bytes of data = 4096 transfer size 32 bytes of overhead + 992 bytes of data = 1024 transfer size. 1/4 the data = 1/4 the overhead. I rearranged my reading like so: resultz = is.read(cbuf,0,3968); resultz = is.read(cbuf,3968,3968); resultz = is.read(cbuf,7936,3968); while (!(is.ready())); // wait for ready resultz = is.read(cbuf,11904,3334); and this grabs 15,238 bytes total. BUT, I still have the quandry of the screwed up multi-bytes. I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. Approx 8% of the data. The bad bytes always seem to take the flavor of 0x2018, 0x2019, x2022, x2030, x201d. Are these maybe errors and I don't know what they enumerate to? I still can't believe some other layer isn't handling putting those bytes together all in one stream for me. Thanks Keith ----- Original Message ----- From: "Keith" To: "Bob Jacobsen" ; "RXTX Developers and Users" Sent: Saturday, March 03, 2007 11:26 AM Subject: Re: [Rxtx] is.read() only returning 3968 bytes > Bob, > > > Interesting numerical coincidence is that (max USB transfer) - (what > > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > > needed to transfer that much data. > > I was thinking along the same lines. I don't know USB well, but I do know > that those numbers were close enough to warrant investigating the > relationship between them. > > > I think what you're seeing is the internal buffering of the USB data > > stream. You'll need some form of higher-level buffering to smooth > > that out. > > Shouldn't the InputStreamReader() and BufferedReader() provide this type of > buffering? Isn't that the idea behind those? > > > All hypotheses need to be tested. In this case, a test would be to > > check for missing data. If this idea is right, you'll get _all_ the > > data, but you won't be missing characters. > > I did start looking at the data. -- I'm getting weird results. > > I tried this: > > loopzz = 0; > > for (looptwo = 0; looptwo < 100000; looptwo++) { > while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > > }} > > So I'm reading one character at a time. The good news is that loopzz is > exactly 15238 at the end of the routine, which is perfectly correct. I > picked looptwo value out of thin air. > > The weird results come in terms of the values, the data isn't correct at > least in one case. Look here: > > 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > > This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). > But the 0x89 was replaced by 0x2030. Why the heck would the returned value > be 0x2030?? Why is the returned byte completely out of range? Why the > multibyte return? > > From InputStream in the API: > > read > public abstract int read() > throws IOExceptionReads the next byte of data from the > input stream. The value byte is returned as an int in the range 0 to 255. If > no byte is available because the end of the stream has been reached, the > value -1 is returned. This method blocks until input data is available, the > end of the stream is detected, or an exception is thrown. > Value should be 0-255. > > > In my application time is really critical, reading 1 byte at a time is > probably not going to work. > > Thanks Eric & Bob for looking at this. > > Keith > From tjarvi at qbang.org Sat Mar 3 12:52:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 12:52:27 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > update: > > I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now > instead of 3968. > > This makes sense. > > 128 bytes of overhead + 3968 bytes of data = 4096 transfer size > 32 bytes of overhead + 992 bytes of data = 1024 transfer size. > > 1/4 the data = 1/4 the overhead. > > I rearranged my reading like so: > > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. > Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? > > I still can't believe some other layer isn't handling putting those bytes > together all in one stream for me. > The layer for this in Serial land is flow control. Software and hardware flow control prevent the overruns you observe. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:54:41 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:54:41 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <001a01c75dcd$c8802a70$6600a8c0@jbh757ktruws7g> Trent, Thanks for taking the time to reply. > I would expect a 20 meg application is going to have different behavior > with the OS than a smaller application with respect to the kernel memory > managment, schedualing, ... Something subtle could be causing problems. Well, at least I know the VCP drivers, the OS, etc can handle 2mbps reliably. Without hiccuping or dropping bytes. The C++ code works reliably without flow control. > The missing data is typical when not using flow control. When the OS > buffering fills, the hardware will start dropping bytes. I'm actually not getting MISSING data, I'm getting CORRUPTED data. If you look at my most recent post, I'm getting these bad bytes in place of the correct values: 0x2018, 0x2019, x2022, x2030, x201d. Why would is.read() return values not in the range of 0-255 ? Thanks. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 08:59:14 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 07:59:14 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: At 1:19 AM -0500 3/3/07, Keith wrote: >If I do a > >resultz = is.read(cbuf,0,15238); in java with RXTX > >where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > >and where resultz is an int, and cbuf is a char [] cbuf, resultz gets >EXACTLY 3968 bytes the first time called. If I call it multiple times, I get >roughly 11k total(less than what is sent), never more than the 3968 bytes >per is.read() call. > >My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 >bytes. Interesting numerical coincidence is that (max USB transfer) - (what you get) = 4096-3968 = 128 bytes is (almost) the size of the headers needed to transfer that much data. I think what you're seeing is the internal buffering of the USB data stream. You'll need some form of higher-level buffering to smooth that out. All hypotheses need to be tested. In this case, a test would be to check for missing data. If this idea is right, you'll get _all_ the data, but you won't be missing characters. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 09:26:14 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 11:26:14 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Bob, > Interesting numerical coincidence is that (max USB transfer) - (what > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > needed to transfer that much data. I was thinking along the same lines. I don't know USB well, but I do know that those numbers were close enough to warrant investigating the relationship between them. > I think what you're seeing is the internal buffering of the USB data > stream. You'll need some form of higher-level buffering to smooth > that out. Shouldn't the InputStreamReader() and BufferedReader() provide this type of buffering? Isn't that the idea behind those? > All hypotheses need to be tested. In this case, a test would be to > check for missing data. If this idea is right, you'll get _all_ the > data, but you won't be missing characters. I did start looking at the data. -- I'm getting weird results. I tried this: loopzz = 0; for (looptwo = 0; looptwo < 100000; looptwo++) { while (is.ready()) { cbuf[loopzz] = (char) is.read(); loopzz++; }} So I'm reading one character at a time. The good news is that loopzz is exactly 15238 at the end of the routine, which is perfectly correct. I picked looptwo value out of thin air. The weird results come in terms of the values, the data isn't correct at least in one case. Look here: 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). But the 0x89 was replaced by 0x2030. Why the heck would the returned value be 0x2030?? Why is the returned byte completely out of range? Why the multibyte return? >From InputStream in the API: read public abstract int read() throws IOExceptionReads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown. Value should be 0-255. In my application time is really critical, reading 1 byte at a time is probably not going to work. Thanks Eric & Bob for looking at this. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 14:44:50 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 13:44:50 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: Java's "char" type is Unicode. I think what you're seeing is a bug in the byte -> Unicode translation. 0x2018, 0x2019 are the curly open and close quotes. There used to be (and might still be) bugs in the conversion of these in a couple of libc versions. Some of the ASCII -> ISO and ISO -> ASCII routines were a little over-ambitious with respect to handling the open and close quotes, and tried to convert them to the "curly" form inappropriately. Try _not_ casting it to char. Bob At 11:26 AM -0500 3/3/07, Keith wrote: >Bob, > >> Interesting numerical coincidence is that (max USB transfer) - (what >> you get) = 4096-3968 = 128 bytes is (almost) the size of the headers >> needed to transfer that much data. > >I was thinking along the same lines. I don't know USB well, but I do know >that those numbers were close enough to warrant investigating the >relationship between them. > >> I think what you're seeing is the internal buffering of the USB data >> stream. You'll need some form of higher-level buffering to smooth >> that out. > >Shouldn't the InputStreamReader() and BufferedReader() provide this type of >buffering? Isn't that the idea behind those? > >> All hypotheses need to be tested. In this case, a test would be to >> check for missing data. If this idea is right, you'll get _all_ the >> data, but you won't be missing characters. > >I did start looking at the data. -- I'm getting weird results. > >I tried this: > >loopzz = 0; > >for (looptwo = 0; looptwo < 100000; looptwo++) { >while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > >}} > >So I'm reading one character at a time. The good news is that loopzz is >exactly 15238 at the end of the routine, which is perfectly correct. I >picked looptwo value out of thin air. > >The weird results come in terms of the values, the data isn't correct at >least in one case. Look here: > >0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > >This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). >But the 0x89 was replaced by 0x2030. Why the heck would the returned value >be 0x2030?? Why is the returned byte completely out of range? Why the >multibyte return? > >>From InputStream in the API: > >read >public abstract int read() > throws IOExceptionReads the next byte of data from the >input stream. The value byte is returned as an int in the range 0 to 255. If >no byte is available because the end of the stream has been reached, the >value -1 is returned. This method blocks until input data is available, the >end of the stream is detected, or an exception is thrown. >Value should be 0-255. > > >In my application time is really critical, reading 1 byte at a time is >probably not going to work. > >Thanks Eric & Bob for looking at this. > >Keith > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 15:10:11 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 17:10:11 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Bob said ..... > Java's "char" type is Unicode. I think what you're seeing is a bug > in the byte -> Unicode translation. Bob -- I think you hit the nail on the head. I was just coming to the same realization here. I knew that something funny was going on because the same bytes always got "corrupted." I'm pretty sure its in the InputStreamReader() functionality where the conversion junk is happening. Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. I don't know if simply changing the cast is going to work. Since the conversion is happening upstream (pun intended), I don't think my cast is doing this. Also I think the compiler forced me to use the cast. I'm still playing around, and I'll report back once I nail it down. Thanks!! Keith From tjarvi at qbang.org Sat Mar 3 15:59:46 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 15:59:46 -0700 (MST) Subject: [Rxtx] Win64 rxtx Testers? Message-ID: I have compiled win64 binaries of rxtx. Are there any users interested in testing them? If so, I'll look into putting them on the web site. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Mar 3 15:35:06 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 14:35:06 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: Because of this and similar problems, JMRI does all it's serial IO using +only+ byte values. It's a but of a pain, as Java wants to go to char and int types a little too aggressively, but it does solve the "uncontrolled conversions" problems. Bob At 5:10 PM -0500 3/3/07, Keith wrote: >Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > >Bob -- I think you hit the nail on the head. > >I was just coming to the same realization here. I knew that something funny >was going on because the same bytes always got "corrupted." > >I'm pretty sure its in the InputStreamReader() functionality where the >conversion junk is happening. > >Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > >I don't know if simply changing the cast is going to work. Since the >conversion is happening upstream (pun intended), I don't think my cast is >doing this. Also I think the compiler forced me to use the cast. -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mark at mdsh.com Sun Mar 4 11:01:33 2007 From: mark at mdsh.com (Mark Himsley) Date: Sun, 04 Mar 2007 18:01:33 +0000 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: <5C01AC72C200388815C04982@bedroom.mdsh.local> On 03 March 2007 14:38 -0500 Keith wrote: > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT > consistent. Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? It looks like you need to use DataInputStream and DataOutputStream. -- Mark Himsley From tjarvi at qbang.org Sun Mar 4 11:35:08 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 11:35:08 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" > > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > > * Line #21 - Not sure if you need a (TM) mark for > the term "Sun" > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > OK. I'm going through this today. Some groups ask if rxtx could be under their license also. I think this is a good example of why I resist multiple licenses and focus on why the current license may not be usable by them. The RXTX project is a convergence of hobby and commercial interests. I happen to do both right now. The problem with licensing is we have to stay on top of them as they change. Clearly, adding more licenses will not make this easier. I'm acting as the hobby person today. RXTX always favors the hobby people. But as we move forward, I'm going to need to bring this to lawyers at work and explain to them what is going on. Others here may have to do this also. I don't anticipate problems or unexpected changes. The goal is a consistant, comprehendable and usable license as close to what we have now as possible. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 14:52:10 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 14:52:10 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (1/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: I'm breaking this into two parts. I expect the second part will need more attention. Comments first, then the changed material below. On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > Thanks > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. OK. RXTX for consitent use. java should not be capitalized because it does not only mean Sun [TM] Java [TM]. An example of this not meaning Java is when people use RXTX with GCJ. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". There are not any contributors that are in all of RXTX yet but I did update the comment to try to reflect the current situation without making it a nightmare to maintain. I looked to see how the Linux kernel does it as a reference point. > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" The URL can be problematic. I have done so below with a time reference. GNU does not provide version information in their URLS. I picture this being a problem when the version 3 comes out. > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > This will be corrected when the copy is updated to the version linked below. ---------------- begin proposed material involved -------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. ----------------- end proposed material involved -------------------- I'll be looking at the linking issue again next. That should be all that remains other than including the 2.1 version. Let me know if you have problems with anything here. I do not want to dilute the material I post next with these housekeeping tasks. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 16:08:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 16:08:36 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: For those that are wondering what is going on here, this next bit is the meat of the changes. We agreed a long time ago to put this disclaimer in. We did a so so job. It was in rxtx 2.0, not well written, ... So some groups using rxtx that would like to ship rxtx so users don't need to download, install, go to the mail-list to find why it failed, ... Then their legal teams tell them section 5 paragraph 2 is a show stopper. That was never the intent. Now going through what remains... > and might need a (TM) suffix to make Sun happy. Added disclaimer at the ended 'all trademarks belong...' > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. OK. As you can see I was trying to adjust GNU text there for the LGPL. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. used dynamically linked terminology. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". I tried to address this more upfront with an intent statement. Let me know if you have problems with it. I also tried to make it a little more clear what was derived from the GNU solution by moving the link location closer to GNU's suggestion. > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > Thats the intent. Here is the combined fixes. Note that only the material in /*-- --*/ is being touched. The new GPL license is there but unmodified. ------------------------ begin proposed new license ------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. | | An executable that contains no derivative of any portion of RXTX, but | is designed to work with RXTX by being dynamically linked with it, | is considered a "work that uses the Library" subject to the terms and | conditions of the GNU Lesser General Public License. | | The following has been added to the RXTX License to remove | any confusion about linking to RXTX. We want to allow in part what | section 5, paragraph 2 of the LGPL does not permit in the special | case of linking over a controlled interface. The intent is to add a | Java Specification Request or standards body defined interface in the | future as another exception but one is not currently available. | | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface | | As a special exception, the copyright holders of RXTX give you | permission to link RXTX with independent modules that communicate with | RXTX solely through the Sun Microsytems CommAPI interface version 2, | regardless of the license terms of these independent modules, and to copy | and distribute the resulting combined work under terms of your choice, | provided that every copy of the combined work is accompanied by a complete | copy of the source code of RXTX (the version of RXTX used to produce the | combined work), being distributed under the terms of the GNU Lesser General | Public License plus this exception. An independent module is a | module which is not derived from or based on RXTX. | | Note that people who make modified versions of RXTX are not obligated | to grant this special exception for their modified versions; it is | their choice whether to do so. The GNU Lesser General Public License | gives permission to release a modified version without this exception; this | exception also makes it possible to release a modified version which | carries forward this exception. | | You should have received a copy of the GNU Lesser General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA | All trademarks belong to their respective owners. --------------------------------------------------------------------------*/ The original GNU Lesser General Public License Follows. GNU LESSER GENERAL PUBLIC LICENSE Version 2.1, February 1999 Copyright (C) 1991, 1999 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. [This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence the version number 2.1.] Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This license, the Lesser General Public License, applies to some specially designated software packages--typically libraries--of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below. When we speak of free software, we are referring to freedom of use, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish); that you receive source code or can get it if you want it; that you can change the software and use pieces of it in new free programs; and that you are informed that you can do these things. To protect your rights, we need to make restrictions that forbid distributors to deny you these rights or to ask you to surrender these rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library or if you modify it. For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights. We protect your rights with a two-step method: (1) we copyright the library, and (2) we offer you this license, which gives you legal permission to copy, distribute and/or modify the library. To protect each distributor, we want to make it very clear that there is no warranty for the free library. Also, if the library is modified by someone else and passed on, the recipients should know that what they have is not the original version, so that the original author's reputation will not be affected by problems that might be introduced by others. Finally, software patents pose a constant threat to the existence of any free program. We wish to make sure that a company cannot effectively restrict the users of a free program by obtaining a restrictive license from a patent holder. Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license. Most GNU software, including some libraries, is covered by the ordinary GNU General Public License. This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs. When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library. We call this license the "Lesser" General Public License because it does Less to protect the user's freedom than the ordinary General Public License. It also provides other free software developers Less of an advantage over competing non-free programs. These disadvantages are the reason we use the ordinary General Public License for many libraries. However, the Lesser license provides advantages in certain special circumstances. For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License. In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software. For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU operating system, as well as its variant, the GNU/Linux operating system. Although the Lesser General Public License is Less protective of the users' freedom, it does ensure that the user of a program that is linked with the Library has the freedom and the wherewithal to run that program using a modified version of the Library. The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, whereas the latter must be combined with the library in order to run. GNU LESSER GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License Agreement applies to any software library or other program which contains a notice placed by the copyright holder or other authorized party saying it may be distributed under the terms of this Lesser General Public License (also called "this License"). Each licensee is addressed as "you". A "library" means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables. The "Library", below, refers to any such software library or work which has been distributed under these terms. A "work based on the Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term "modification".) "Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library. Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does. 1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) The modified work must itself be a software library. b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change. c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License. d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful. (For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library. In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. 4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange. If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code. 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables. When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law. If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.) Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself. 6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications. You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things: a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.) b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. c) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution. d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place. e) Verify that the user has already received a copy of these materials or that you have already sent this user a copy. For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute. 7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things: a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above. b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work. 8. You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 9. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Library (or any work based on the Library), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Library or works based on it. 10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties with this License. 11. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply, and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 12. If the distribution and/or use of the Library is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Library under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 13. The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation. 14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Libraries If you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the ordinary General Public License). To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Also add information on how to contact you by electronic and paper mail. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the library, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the library `Frob' (a library for tweaking knobs) written by James Random Hacker. , 1 April 1990 Ty Coon, President of Vice That's all there is to it! ------------------------ end of proposed license ------------------ -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sun Mar 4 16:26:04 2007 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 04 Mar 2007 17:26:04 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <45EB558C.3010609@cox.net> Bob Jacobsen wrote: > Because of this and similar problems, JMRI does all it's serial IO > using +only+ byte values. It's a but of a pain, as Java wants to go > to char and int types a little too aggressively, but it does solve > the "uncontrolled conversions" problems. Anytime that you are reading bytes of data that is not printable, unicode text, in Java, you really need to stay away from the Readers. Use input stream only, or you will see unicode valued byte groups converted to unicode "char" values. Gregg Wonderly From joachim at buechse.de Mon Mar 5 04:23:48 2007 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 5 Mar 2007 12:23:48 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> The behaviour is exactly what you asked for in you code. is = new BufferedReader(new InputStreamReader(port.getInputStream())); Readers return Text (ie unicode chars) not bytes. You instantiate the InputStreamReader without saying which charset you want, which means "platform default". As this is on Windows, it will convert Windows characters to equivalent unicode characters. If you want to read bytes, read bytes not Text. Reading bytes is done with InputStream and BufferedInputStream. BTW: The InputStream and Reader methods that read arrays are not guarenteed to fill up the array. You always have to check what you really got, and advance your index accordingly. A typical "read up to 32k" method looks like this: InputStream is= ... // -- determine the max buffer size int len= is.available(); if (len == 0) { len= 32 * 1024; } // -- read all available data byte[] buffer= new byte[len]; int pos= 0; int read; do { read= is.read(buffer, pos, buffer.length - pos); pos= pos + read; } while (read != -1 && pos < buffer.length); Best regards, Joachim --- Joachim B?chse Phone: +41 44 500 2604 Buechse Consulting Hadlaubsteig 2 CH-8006 Z?rich On 03.03.2007, at 23:10, Keith wrote: > Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > > Bob -- I think you hit the nail on the head. > > I was just coming to the same realization here. I knew that > something funny > was going on because the same bytes always got "corrupted." > > I'm pretty sure its in the InputStreamReader() functionality where the > conversion junk is happening. > > Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > > I don't know if simply changing the cast is going to work. Since the > conversion is happening upstream (pun intended), I don't think my > cast is > doing this. Also I think the compiler forced me to use the cast. > > I'm still playing around, and I'll report back once I nail it down. > > Thanks!! > > Keith > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Mon Mar 5 07:25:46 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 05 Mar 2007 08:25:46 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> Message-ID: <45EC286A.8060608@cox.net> Joachim Buechse wrote: > BTW: The InputStream and Reader methods that read arrays are not > guarenteed to fill up the array. You always have to check what you > really got, and advance your index accordingly. A typical "read up to > 32k" method looks like this: > > InputStream is= ... > // -- determine the max buffer size > int len= is.available(); > if (len == 0) { > len= 32 * 1024; > } > // -- read all available data > byte[] buffer= new byte[len]; > int pos= 0; > int read; > do { > read= is.read(buffer, pos, buffer.length - pos); > pos= pos + read; > } while (read != -1 && pos < buffer.length); > My preferred structure is. byte arr[ len ]; int cnt; int off = 0; while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { off += cnt; } This keeps you from adding -1 to pos when the read returns -1. It also skips out when the read is 0 bytes which, is not a described EOF in InputStream java docs, but is a condition I want to be aware of. Gregg Wonderly From joachim at buechse.de Tue Mar 6 02:52:58 2007 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 6 Mar 2007 10:52:58 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <45EC286A.8060608@cox.net> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: The code I copied was from a file resource reader, it shouldn't really be applied to networking/external IO code. Mea culpa. However aborting when you get 0 from read is not always what you want either (you kind of indicated that already). Some unix java implementations will return 0 if the kernel read was aborted with EINTER, which is rarely the point where you want to abort your read - at least not without further checks. A "complete" solution always depends on the events you need to handle and the time the total read could take in reality. In some cases it's worth checking Thread.isInterrupted() in the loop, some code re-loops on 0 but only a limited number of times, some check a total timeout limit, etc... Best regards, Joachim On 05.03.2007, at 15:25, Gregg Wonderly wrote: > My preferred structure is. > > byte arr[ len ]; > int cnt; > int off = 0; > while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { > off += cnt; > } > > This keeps you from adding -1 to pos when the read returns -1. It > also skips > out when the read is 0 bytes which, is not a described EOF in > InputStream java > docs, but is a condition I want to be aware of. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Mar 6 14:47:44 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 Mar 2007 14:47:44 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: Just FYI, rxtx will usually not break out on EINTER. The code in the native library usually does something close to this: do { read(...) } while ( !done && errno==EINTR ); Obviously there is a little more involved but it will retry on EINTER if not done. On Tue, 6 Mar 2007, Joachim Buechse wrote: > The code I copied was from a file resource reader, it shouldn't > really be applied to networking/external IO code. Mea culpa. > > However aborting when you get 0 from read is not always what you want > either (you kind of indicated that already). Some unix java > implementations will return 0 if the kernel read was aborted with > EINTER, which is rarely the point where you want to abort your read - > at least not without further checks. A "complete" solution always > depends on the events you need to handle and the time the total read > could take in reality. In some cases it's worth checking > Thread.isInterrupted() in the loop, some code re-loops on 0 but only > a limited number of times, some check a total timeout limit, etc... > > Best regards, > Joachim > > On 05.03.2007, at 15:25, Gregg Wonderly wrote: >> My preferred structure is. >> >> byte arr[ len ]; >> int cnt; >> int off = 0; >> while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { >> off += cnt; >> } >> >> This keeps you from adding -1 to pos when the read returns -1. It >> also skips >> out when the read is 0 bytes which, is not a described EOF in >> InputStream java >> docs, but is a condition I want to be aware of. >> >> Gregg Wonderly >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 gjhanna at gmail.com Thu Mar 8 13:42:52 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Fri, 9 Mar 2007 09:42:52 +1300 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? Message-ID: I've just struck an issue using rxtx in a multi-threaded environment: If I have 3 threads trying to open *the same* comm-port I get a deadlock in CommPortIdentifier.open If I have just 2, it works fine - I get a PortInUseException which is nice and I can handle it. The 3 thread->deadlock thing is causing me issues. (Sample code below). This is from the java thread-dump Found one Java-level deadlock: ============================= "Thread-2": waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object ), which is held by "Thread-1" "Thread-1": waiting to lock monitor 0x0003e9cc (object 0x2450e108, a gnu.io.CommPortIdentifier), which is held by "Thread-2" Java stack information for the threads listed above: =================================================== "Thread-2": at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:329) - waiting to lock <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) "Thread-1": at java.lang.Object.wait(Native Method) - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) - locked <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) (Apart from this, rxtx is working fantastically for us). I'm thinking I'll have to implement some sort of locking mechanism that *doesn't* use java synchronization to prevent this situation. (Which doesn't sound like a good idea to me). Any ideas? Thanks, Greg Hanna ============= RXTXLockTest.java ======================================== import gnu.io.CommPort; import gnu.io.CommPortIdentifier; /** * @author Greg Hanna * Minimal code to create a deadlock with rxtx in multithreaded open */ public class RXTXLockTest { public static void main(String[] args) { try { CommPortIdentifier cpiCom1 = CommPortIdentifier.getPortIdentifier ("COM14"); OpenThread t1 = new OpenThread (" one ", cpiCom1); OpenThread t2 = new OpenThread (" two ", cpiCom1); OpenThread t3 = new OpenThread (" 003 ", cpiCom1); t1.start(); t2.start(); t3.start(); // comment this out and it runs with (expected) PortInUseException } catch (Exception e) { e.printStackTrace(); } } } class OpenThread extends Thread { String name; CommPortIdentifier cpi; CommPort cp; public OpenThread (String name, CommPortIdentifier cpi) { this.name = name; this.cpi = cpi; System.out.println (System.currentTimeMillis() + name + " thread created"); } public void run () { try { System.out.println (System.currentTimeMillis() + name + " opening"); cp = cpi.open(name, 2000); System.out.println (System.currentTimeMillis() + name + " opened - sleeping"); sleep (2000); // do the serial comms with the device. System.out.println (System.currentTimeMillis() + name + " slept - closing"); cp.close(); System.out.println (System.currentTimeMillis() + name + " closed - exiting"); } catch (Exception e) { System.out.println ("Error in thread: " + name ); e.printStackTrace(); } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070308/d9a163c5/attachment-0082.html From eu259473 at tele2.it Fri Mar 9 02:46:20 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 09 Mar 2007 10:46:20 +0100 Subject: [Rxtx] rxtx: tru64 unix make fails Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070309/3b654523/attachment-0082.html From lyon at docjava.com Fri Mar 9 03:58:32 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 Mar 2007 05:58:32 -0500 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi All, The deadlock issue is one that I have been thinking about for some time now. It seems to me that we need a resource manager that enables assignment to a known process. The one thing that seems important about serial ports is that two applications should not use the same serial port at the same time. When this happens, it throws an exception. OK. The exception is a response to a lock condition that arises from an unavailable resource. An abstract implementation (not born of native methods) might assign a serial port to an application, until the application releases it (or is forced to release it by some kill mechanism). Some resources (like a registry) can be reused. But others, like the serial port, cannot. In the case of the serial port, we would like, I think, to have the flyweight design pattern without sharing and with object assignment tracking. A means of breaking deadlock (like a leasing mechanism) seems very useful, to me. My guess is that we can serialize the state of the Parametric Singleton Pattern (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) into the Preferences of the System. Preferences.systemRoot() might help with that. When a resource is checked out, the lease time and owner are listed. A thread that does this can be killed, but applications outside of Java are problematic. There is a compelling problem here. It is not just serial ports. Sound cards, cameras, microphones, files, tape drives, etc. All are consumed resources that are assigned to an application (or user) and deprive other applications, or users, from use. What, if anything, should we do? At present we throw PortInUseExceptions. Is that it? Can we do better? OK, the port is in use. Now what? Do I have to be root to go remove lock files and kill applications? Is there a better way? Thanks! - Doug >I've just struck an issue using rxtx in a multi-threaded environment: > >If I have 3 threads trying to open *the same* >comm-port I get a deadlock in >CommPortIdentifier.open >If I have just 2, it works fine - I get a >PortInUseException which is nice and I can >handle it. > >The 3 thread->deadlock thing is causing me issues. >(Sample code below). > >This is from the java thread-dump > >Found one Java-level deadlock: >============================= >"Thread-2": > waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), > which is held by "Thread-1" >"Thread-1": > waiting to lock monitor 0x0003e9cc (object >0x2450e108, a gnu.io.CommPortIdentifier ), > which is held by "Thread-2" > >Java stack information for the threads listed above: >=================================================== >"Thread-2": > at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) > - waiting to lock <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) >"Thread-1": > at java.lang.Object.wait(Native Method) > - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) > - locked <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) > > >(Apart from this, rxtx is working fantastically for us). > >I'm thinking I'll have to implement some sort of >locking mechanism that *doesn't* use java >synchronization to prevent this situation. >(Which doesn't sound like a good idea to me). > >Any ideas? > >Thanks, > >Greg Hanna > >============= RXTXLockTest.java ======================================== > >import gnu.io.CommPort; >import gnu.io.CommPortIdentifier; > >/** > * @author Greg Hanna > * Minimal code to create a deadlock with rxtx in multithreaded open > */ >public class RXTXLockTest { > ? > ?public static void main(String[] args) { > ?try { > ?CommPortIdentifier cpiCom1 = >CommPortIdentifier.getPortIdentifier ("COM14"); > ?OpenThread t1 = new OpenThread (" one ", cpiCom1); > ?OpenThread t2 = new OpenThread (" two ", cpiCom1); > ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); > ?t1.start(); > ?t2.start(); > ?t3.start(); // comment this out >and it runs with (expected) PortInUseException > ?} catch (Exception e) { > ?e.printStackTrace(); > ?} > ?} >} > >class OpenThread extends Thread { > ?String name; > ?CommPortIdentifier cpi; > ?CommPort cp; > ?public OpenThread (String name, CommPortIdentifier cpi) { > ? this.name = name; > ?this.cpi = cpi; > ?System.out.println >(System.currentTimeMillis() + name + " thread >created"); > ?} > ?public void run () { > ?try { > ?System.out.println >(System.currentTimeMillis() + name + " opening"); > ?cp = cpi.open(name, 2000); > ?System.out.println >(System.currentTimeMillis() + name + " opened - >sleeping"); > ?sleep (2000); // do the serial comms with the device. > ?System.out.println >(System.currentTimeMillis() + name + " slept - >closing"); > ?cp.close(); > ?System.out.println >(System.currentTimeMillis() + name + " closed - >exiting"); > ?} catch (Exception e) { > System.out.println ("Error in thread: " + name ); > ?e.printStackTrace(); > ?} > ?} >} > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Mar 9 06:37:45 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 Mar 2007 06:37:45 -0700 (MST) Subject: [Rxtx] rxtx: tru64 unix make fails In-Reply-To: References: Message-ID: On Fri, 9 Mar 2007, "Giuseppe Marchese" wrote: > Sorry for delay. > ? > This is log for ./configure and make > error. > ? > thanks for attention > ? > Make: '%.java,$(TOP)/$(CLASSDEST)/%.class,$(wildcard $(SPATH)/*.java)': extra chars.? > Stop. > Hi Giuseppe You need to use GNU make with the Makefile. I suspect the tru64 make is not happy with those rules. > configure: exit 0 Looks like configure is fairly happy. From tjarvi at qbang.org Sat Mar 10 07:43:51 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 07:43:51 -0700 (MST) Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi Doug I have very little time to look into this further but what we could do is open up an rxtx 3 devel branch in which a proof of concept could be worked on. It could be the proof of concept for a JSR others including Sun could look at/work on or parts of it could be recycled in a JSR. I'm working very hard on rxtx right now but it does not show. I'm looking at win64, mac intel/ppc, usb bluetooth and usb serial dongles. Some are going to be more tested than others but they are all on the plate. I'll be pushing all the fixes upstream when they are done. So I'm very busy in 2.1 but we could open a new branch. On Fri, 9 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > The deadlock issue is one that I have been thinking about > for some time now. > It seems to me that we need a resource manager that enables assignment > to a known process. > > The one thing that seems important about serial > ports is that two applications should not use the > same serial port at the same time. When this > happens, it throws an exception. > OK. > > The exception is a response to a lock condition that > arises from an unavailable resource. > > An abstract implementation (not born of native methods) might > assign a serial port to an application, until the > application releases it (or is forced to release > it by some kill mechanism). > > Some resources (like a registry) can be reused. > But others, like the serial port, > cannot. > > In the case of the serial port, we would like, I think, to > have the flyweight design pattern > without sharing and with object assignment tracking. > A means of breaking deadlock (like a leasing > mechanism) seems very useful, to me. > > My guess is that we can serialize the state of the Parametric Singleton Pattern > (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) > into the Preferences of the System. Preferences.systemRoot() might help > with that. When a resource is checked out, the lease time and owner are > listed. A thread that does this can be killed, but applications outside of Java > are problematic. > > There is a compelling problem here. It is not just serial ports. > Sound cards, cameras, microphones, files, tape drives, etc. All are consumed > resources that are assigned to an application (or > user) and deprive other applications, > or users, from use. > > What, if anything, should we do? At present we throw PortInUseExceptions. > Is that it? > Can we do better? > OK, the port is in use. Now what? > Do I have to be root to go remove lock files and kill applications? > Is there a better way? > > Thanks! > - Doug > >> I've just struck an issue using rxtx in a multi-threaded environment: >> >> If I have 3 threads trying to open *the same* >> comm-port I get a deadlock in >> CommPortIdentifier.open >> If I have just 2, it works fine - I get a >> PortInUseException which is nice and I can >> handle it. >> >> The 3 thread->deadlock thing is causing me issues. >> (Sample code below). >> >> This is from the java thread-dump >> >> Found one Java-level deadlock: >> ============================= >> "Thread-2": >> waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), >> which is held by "Thread-1" >> "Thread-1": >> waiting to lock monitor 0x0003e9cc (object >> 0x2450e108, a gnu.io.CommPortIdentifier ), >> which is held by "Thread-2" >> >> Java stack information for the threads listed above: >> =================================================== >> "Thread-2": >> at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) >> - waiting to lock <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> "Thread-1": >> at java.lang.Object.wait(Native Method) >> - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) >> - locked <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> >> >> (Apart from this, rxtx is working fantastically for us). >> >> I'm thinking I'll have to implement some sort of >> locking mechanism that *doesn't* use java >> synchronization to prevent this situation. >> (Which doesn't sound like a good idea to me). >> >> Any ideas? >> >> Thanks, >> >> Greg Hanna >> >> ============= RXTXLockTest.java ======================================== >> >> import gnu.io.CommPort; >> import gnu.io.CommPortIdentifier; >> >> /** >> * @author Greg Hanna >> * Minimal code to create a deadlock with rxtx in multithreaded open >> */ >> public class RXTXLockTest { >> ? >> ?public static void main(String[] args) { >> ?try { >> ?CommPortIdentifier cpiCom1 = >> CommPortIdentifier.getPortIdentifier ("COM14"); >> ?OpenThread t1 = new OpenThread (" one ", cpiCom1); >> ?OpenThread t2 = new OpenThread (" two ", cpiCom1); >> ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); >> ?t1.start(); >> ?t2.start(); >> ?t3.start(); // comment this out >> and it runs with (expected) PortInUseException >> ?} catch (Exception e) { >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> class OpenThread extends Thread { >> ?String name; >> ?CommPortIdentifier cpi; >> ?CommPort cp; >> ?public OpenThread (String name, CommPortIdentifier cpi) { >> ? this.name = name; >> ?this.cpi = cpi; >> ?System.out.println >> (System.currentTimeMillis() + name + " thread >> created"); >> ?} >> ?public void run () { >> ?try { >> ?System.out.println >> (System.currentTimeMillis() + name + " opening"); >> ?cp = cpi.open(name, 2000); >> ?System.out.println >> (System.currentTimeMillis() + name + " opened - >> sleeping"); >> ?sleep (2000); // do the serial comms with the device. >> ?System.out.println >> (System.currentTimeMillis() + name + " slept - >> closing"); >> ?cp.close(); >> ?System.out.println >> (System.currentTimeMillis() + name + " closed - >> exiting"); >> ?} catch (Exception e) { >> System.out.println ("Error in thread: " + name ); >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 mm at UDel.Edu Sat Mar 10 14:48:32 2007 From: mm at UDel.Edu (Mike Markowski) Date: Sat, 10 Mar 2007 16:48:32 -0500 Subject: [Rxtx] rxtx and Sun's comm api Message-ID: <45F327B0.2060004@udel.edu> Hi all, I joined the list a few days ago and apologize for what is likely a frequently asked question, though I haven't yet found it anywhere. I learned about rxtx.org through the readme on Sun's version 2 of their comms api. They give recommendations in that readme regarding how a better comms api should be written. Is this the aim of rxtx.org? I wrote an app on my linux box using the Sun comms api (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the fact that only linux and Solaris are supported. So I'm glad to find rxtx.org and am just reading up on how make the conversion so Windows users will be able to run the program as well. At the same time I'm just curious if rxtx.org and Sun are both heading in the same direction. Thanks for any background or historical info. Feel free to point me to any www pages if my googling has just completely missed the target! Thanks again, Mike From tjarvi at qbang.org Sat Mar 10 15:35:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 15:35:25 -0700 (MST) Subject: [Rxtx] rxtx and Sun's comm api In-Reply-To: <45F327B0.2060004@udel.edu> References: <45F327B0.2060004@udel.edu> Message-ID: On Sat, 10 Mar 2007, Mike Markowski wrote: > Hi all, > > I joined the list a few days ago and apologize for what is likely a > frequently asked question, though I haven't yet found it anywhere. I > learned about rxtx.org through the readme on Sun's version 2 of their > comms api. They give recommendations in that readme regarding how a > better comms api should be written. Is this the aim of rxtx.org? > > I wrote an app on my linux box using the Sun comms api > (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the > fact that only linux and Solaris are supported. So I'm glad to find > rxtx.org and am just reading up on how make the conversion so Windows > users will be able to run the program as well. At the same time I'm > just curious if rxtx.org and Sun are both heading in the same direction. > > Thanks for any background or historical info. Feel free to point me to > any www pages if my googling has just completely missed the target! > I do not have any news (good or bad) concerning RXTX and Sun working together but perhaps others here do. The main goal of RXTX is to expose POSIX termios interfaces to java users. The future support of javax.comm is questionable. We do not have resources for everything. gnu.io (RXTX 2.1) will be supported going forward and functions the same as CommAPI 2.0. If you have control of the source code you are working with, I would not advise using CommAPI 2.0 javax.comm. We do support CommAPI 2.0 javax.comm for older applications but I do not think that will last much longer for practical reasons. The download interest in CommAPI 2.0 javax.comm support is becomming negligible on this end. There has been discussion of a JSR effort but I do not know of any status change since it was mentioned. One problem with a JSR is that even a light weight process is going to be difficult for RXTX at this time. Maybe that will change in the future but then again it may not. For now, we are just going forward 'as is' in rxtx 2.1 with package gnu.io while trying as a secondary effort to backport the changes to rxtx 2.0 for javax.comm support for users that do not have a choice. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Mar 11 07:19:40 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 11 Mar 2007 08:19:40 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: Hi All, I have been a proponent of a JSR that makes use of RXTX. I have executed the proper agreements with Sun. At this point we are in the: Early Draft Review of Draft Specifications Stage. The best thing to do is to enter the quiet period and create a specification. The question of exactly how we, as a group, want to approach this problem, remains open. Typically, we should have both a specification and a reference implementation. Thus, it would be to our best advantage to have a nice, stable, cross platform RXTX distro that adheres to the groups specification. Now, from a specification standpoint, my personal view on the matter is that we create a series of interfaces, with nice documentation (or at least javadoc). Is this a good idea? Should we have a pure interface specification for the communication API? There are several issues, in my mind, which still weigh on us. Hot-pluggable dongles, long discovery process on pop-up ports, lack of uniformity on device names, lack of uniformity on locking, a precise understanding of how the SerialPortResourceManager works (or even if we should have one). The more questions we answer in our reference implementation, the better our specification will get. RXTX is a good working prototype, but, I don't know if that is what we want to use for a specification. Here is what I have for a CommPortInterface: */ public interface CommPortInterface { /** * @return a string representation of this port. */ String toString(); /** * Gets the name of the communications port. This name should correspond to * something the user can identify, like the label on the hardware. * @return name of the port */ String getName(); /** * @return an input stream that can be used to read data from the * communications port. If the port doesn't support reading data, this * method returns null. *

* The blocking behaviour of this input stream depends on the threshold * and timeout values, as shown below for a read buffer size of n * bytes: * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ThresholdTimeoutBlocking behaviour
StateValueStateValue
disableddisabledblock until data is available
enabledm bytesdisabledblock until min(m, n) bytes are available
disabledenabledt msblock for t ms or until data is available
enabledm bytesenabledt msblock for t ms or until min(m, n) bytes are * available
* @throws java.io.IOException */ InputStream getInputStream() throws IOException; /** * @return an output stream that can be used to send data to the * communications port. If the port doesn't support sending data, this * method returns null. * @throws java.io.IOException */ OutputStream getOutputStream() throws IOException; /** * Closes this communications port. * All PortOwnershipListeners will be? * notified of this change of ownership. Further method calls on this? * object will throw IllegalStateException. Further calls on the? * associated InputStream or OutputStream will throw IOException. *

* Close does not block. Undelivered data is discarded. Blocked read and? * write operations are aborted if the underlying operating systems? * supports an IO abort mechanism. To await the delivery of undelivered? * data call OutputStream.flush() or OutputStream.close() before calling? * Port.close(). */ void close(); /** * Enables receive threshold. * When the specified threshold number of bytes are retrieved, read will * return immediately. * * @param thresh the number of bytes in the input buffer * @throws gnu.io.UnsupportedCommOperationException * if receive threshold is * not supported by the driver * @see #disableReceiveThreshold */ void enableReceiveThreshold(int thresh) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive threshold. * * @see #enableReceiveThreshold */ void disableReceiveThreshold(); /** * @return true if receive threshold is enabled. * * @see #enableReceiveThreshold */ boolean isReceiveThresholdEnabled(); /** * @return the receive threshold value. If receive threshold is diabled * or not supported, this value is meaningless. * * @see #enableReceiveThreshold */ int getReceiveThreshold(); /** * Enables receive timeout. * When the specified number of milliseconds have elapsed, read will * return immediately. * * @param rcvTimeout the number of milliseconds to block for * @throws gnu.io.UnsupportedCommOperationException * if receive timeout is * not supported by the driver * @see #disableReceiveTimeout */ void enableReceiveTimeout(int rcvTimeout) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive timeout. * * @see #enableReceiveTimeout */ void disableReceiveTimeout(); /** * @return true if receive timeout is enabled. * * @see #enableReceiveTimeout */ boolean isReceiveTimeoutEnabled(); /** * @return the receive timeout value. If receive timeout is diabled * or not supported, this value is meaningless. * * @see #enableReceiveTimeout */ int getReceiveTimeout(); /** * Enables receive framing. * The supplied byte value in the input suggests the end of the received * frame, and read returns immediately. Only the low 8 bits of the * supplied value are significant. * * @param framingByte the frame delimiter * @throws gnu.io.UnsupportedCommOperationException * if receive framing is * not supported by the driver * @see #disableReceiveFraming */ void enableReceiveFraming(int framingByte) throws UnsupportedCommOperationException; /** * Disables receive framing. * * @see #enableReceiveFraming */ void disableReceiveFraming(); /** * @return true if receive framing is enabled. * * @see #enableReceiveFraming */ boolean isReceiveFramingEnabled(); /** * @return true if receive framing byte. If receive framing is diabled * or not supported, this value is meaningless. * * @see #enableReceiveFraming */ int getReceiveFramingByte(); /** * Sets the input buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setInputBufferSize(int size); /** * @return the input buffer size. * The driver may choose not to report correct values. */ int getInputBufferSize(); /** * Sets the output buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setOutputBufferSize(int size); /** * @return the output buffer size. * The driver may choose not to report correct values. */ int getOutputBufferSize(); } What do you think of that? Note the wishy washy nature of the spec: The driver may choose to ignore this method. Is that good enough for us? Thanks! - Doug From ra85551 at gmail.com Sun Mar 11 08:44:45 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Sun, 11 Mar 2007 17:44:45 +0300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hello, world! I am writing application that communicates with modem via AT commands. My OS is Linux Kubuntu Feisty Herd, to ensure that my application will run properly under Windows XP I installed VMWare server. When I tried to send AT command and evaluate modem answer under WinXP @ VMWare server, I actually didn't receive anything. I think that VM settings are right, because I do can communicate with modem by using standard HyperTerminall as well as I can do on native Windows. So, why RXTX doesn't work under VM, but works under Linux and pure Windows XP (i tested it there) well? The send/receive method code follows. private String sendATCommand(String command, final String waitFor, final boolean isRegex, boolean isAddCRLF, long timeout) throws BeaconConnectException { final long POLL_PERIOD = 100; final int BUFFER_SIZE = 512; final byte[] buffer = new byte[BUFFER_SIZE]; final InputStream serialInput; final OutputStream serialOutput; try { serialInput = serialPort.getInputStream(); if (command != null) { serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } } catch (IOException e) { throw new MyException("serial I/O error"); } TimerTask task = new TimerTask() { int offset = 0; int bytesRead; public synchronized void run() { try { if (serialInput.available() > 0) { bytesRead = serialInput.read(buffer, offset, BUFFER_SIZE - offset); } else { return; } } catch (IOException e) { // do nothing - maybe next time we'll read something } offset += bytesRead; if (waitFor != null) { String temporary = new String(buffer, 0, offset).trim(); if (isRegex && temporary.matches(waitFor) || temporary.contains(waitFor)) { cancel(); notify(); } } } }; Timer timer = new Timer(); timer.schedule(task, POLL_PERIOD, POLL_PERIOD); synchronized (task) { try { task.wait(timeout); task.cancel(); } catch (InterruptedException e) { } } //Cut off leading and trailing CRs, LFs and zeroes String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); System.out.println(response); return response; } -- Pavel Parkhomenko From tjarvi at qbang.org Sun Mar 11 11:48:22 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:48:22 -0600 (MDT) Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: On Sun, 11 Mar 2007, Pavel Parkhomenko wrote: > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. > > private String sendATCommand(String command, final String waitFor, > final boolean isRegex, boolean isAddCRLF, long timeout) > throws BeaconConnectException > { > final long POLL_PERIOD = 100; > final int BUFFER_SIZE = 512; > final byte[] buffer = new byte[BUFFER_SIZE]; > final InputStream serialInput; > final OutputStream serialOutput; > try > { > serialInput = serialPort.getInputStream(); > if (command != null) > { > serialOutput = serialPort.getOutputStream(); > if (isAddCRLF) > { > command += "\r\n"; > } > System.out.println(command); > serialOutput.write(command.getBytes()); > } > } > catch (IOException e) > { > throw new MyException("serial I/O error"); > } > > TimerTask task = new TimerTask() > { > int offset = 0; > int bytesRead; > public synchronized void run() > { > try > { > if (serialInput.available() > 0) > { > bytesRead = serialInput.read(buffer, offset, > BUFFER_SIZE - offset); > } > else > { > return; > } > } > catch (IOException e) > { > // do nothing - maybe next time we'll read something > } > offset += bytesRead; > if (waitFor != null) > { > String temporary = new String(buffer, 0, offset).trim(); > if (isRegex && temporary.matches(waitFor) || > temporary.contains(waitFor)) > { > cancel(); > notify(); > } > } > } > }; > > Timer timer = new Timer(); > timer.schedule(task, POLL_PERIOD, POLL_PERIOD); > synchronized (task) { > try > { > task.wait(timeout); > task.cancel(); > } > catch (InterruptedException e) > { > } > } > //Cut off leading and trailing CRs, LFs and zeroes > String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); > System.out.println(response); > return response; > } > > > Hi Pavel VMWare should not be a problem. I've used it in the past - though not with a modem. Make sure nothing else is using the modem. Then look in the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an example that should work. Note that modems could care less what OS is on top. If you are trying to match new lines to the OS and sending it to the mode for AT commands, thats probably a mistake. Also it would not hurt to print out the individual bytes that you are sending to make sure they did not get mangled along the path. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 11:55:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:55:48 -0600 (MDT) Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: On Sun, 11 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > I have been a proponent of a JSR that makes > use of RXTX. I have executed the proper agreements with Sun. > > At this point we are in the: > Early Draft Review of Draft Specifications Stage. > > The best thing to do is to enter the quiet period and create > a specification. The question of exactly how we, as a group, > want to approach this problem, remains open. > > Typically, we should have both a specification and a reference > implementation. Thus, it would be to our best advantage to have > a nice, stable, cross platform RXTX distro that adheres to the > groups specification. > > Now, from a specification standpoint, my personal view on the matter is > that we create a series of interfaces, with nice documentation (or at least > javadoc). > > Is this a good idea? Should we have a pure interface specification for > the communication API? > > There are several issues, in my mind, which still weigh on us. > Hot-pluggable dongles, long discovery process on pop-up ports, > lack of uniformity on device names, lack of uniformity on locking, > a precise understanding of how the SerialPortResourceManager > works (or even if we should have one). > > The more questions we answer in our reference implementation, the > better our specification will get. RXTX is a good working prototype, > but, I don't know if that is what we want to use for a specification. > > Here is what I have for a CommPortInterface: > */ > public interface CommPortInterface { Hi Doug, I can start going through the method interfaces later this week and giving feedback. I would suggest that the JSR should not be too generic in nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel drivers that intend to look like EIA232 ports at the kernel driver level. some ideas: EIA232PortInterface TermiosInterface SerialPortInterface Something that differentiates this from thing like USB, I2C, ... which should not have to deal with legacy serial claiming to be the comm api. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 12:52:19 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 12:52:19 -0600 (MDT) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: No news is good news with these posts. I'll start the process of pinging legal a week from Monday on my end if nobody has objections to the proposal. I just want to make sure everyone has time to raise objections. Obviously, anyone can fork from a previous version if they don't like the new license. I suspect we can avoid that though. On Sun, 4 Mar 2007, Trent Jarvi wrote: > > For those that are wondering what is going on here, this > next bit is the meat of the changes. We agreed a long time > ago to put this disclaimer in. We did a so so job. It was > in rxtx 2.0, not well written, ... So some groups using > rxtx that would like to ship rxtx so users don't need to > download, install, go to the mail-list to find why it failed, > ... Then their legal teams tell them section 5 paragraph 2 > is a show stopper. > > That was never the intent. > > > Now going through what remains... > >> and might need a (TM) suffix to make Sun happy. > > Added disclaimer at the ended 'all trademarks belong...' > >> * Line #15ff - static vs. dynamic linking - you did >> not transcribe the text from the "controlled >> interface exception" when writing this text - and >> this was good so, because these terms originally >> refer to the GPL rather than the LGPL. I think though, >> that these 4 lines are the most important ones and >> should thus be really really clear. I hope that I >> meet your original intent with the following >> suggestions: >> 1.) Instead of "A program.." it would be better to >> say "An exectuable.." in order to be closer to >> the LGPL text. > > OK. As you can see I was trying to adjust GNU text there > for the LGPL. > >> 2.) It would be better to say .. "by being dynamically >> linked with it" to clearly indicate that dynamic >> linking is meant. The matter of compilation is >> already covered by the LGPL so mentioning it again >> just leads to confusion. > > used dynamically linked terminology. > >> 3.) It would be better to say .. "is considered a >> work that uses the library in contrast to section >> 5 of the LGPL, so the terms of the LGPL do not >> apply to the resulting executable". > > I tried to address this more upfront with an intent statement. > Let me know if you have problems with it. I also tried to > make it a little more clear what was derived from the GNU > solution by moving the link location closer to GNU's suggestion. > >> >> Note that LGPL section 5 says: ..."is called a >> "work that uses the Library". Such a work, in isolation, >> is not a derivative work of the Library, and therefore >> falls outside the scope of this License." >> The next paragraph of the LGPL is exactly the problematic >> one that I hope is clarified by the exception terms you >> give. >> > > Thats the intent. Here is the combined fixes. Note that only the > material in /*-- --*/ is being touched. The new GPL license is > there but unmodified. > > > ------------------------ begin proposed new license ------------------- > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Lesser General Public > | License as published by the Free Software Foundation; either > | version 2.1 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Lesser General Public License for more details. > | > | An executable that contains no derivative of any portion of RXTX, but > | is designed to work with RXTX by being dynamically linked with it, > | is considered a "work that uses the Library" subject to the terms and > | conditions of the GNU Lesser General Public License. > | > | The following has been added to the RXTX License to remove > | any confusion about linking to RXTX. We want to allow in part what > | section 5, paragraph 2 of the LGPL does not permit in the special > | case of linking over a controlled interface. The intent is to add a > | Java Specification Request or standards body defined interface in the > | future as another exception but one is not currently available. > | > | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface > | > | As a special exception, the copyright holders of RXTX give you > | permission to link RXTX with independent modules that communicate with > | RXTX solely through the Sun Microsytems CommAPI interface version 2, > | regardless of the license terms of these independent modules, and to copy > | and distribute the resulting combined work under terms of your choice, > | provided that every copy of the combined work is accompanied by a complete > | copy of the source code of RXTX (the version of RXTX used to produce the > | combined work), being distributed under the terms of the GNU Lesser General > | Public License plus this exception. An independent module is a > | module which is not derived from or based on RXTX. > | > | Note that people who make modified versions of RXTX are not obligated > | to grant this special exception for their modified versions; it is > | their choice whether to do so. The GNU Lesser General Public License > | gives permission to release a modified version without this exception; this > | exception also makes it possible to release a modified version which > | carries forward this exception. > | > | You should have received a copy of the GNU Lesser General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > | All trademarks belong to their respective owners. > --------------------------------------------------------------------------*/ > > The original GNU Lesser General Public License Follows. > > > GNU LESSER GENERAL PUBLIC LICENSE > Version 2.1, February 1999 > > Copyright (C) 1991, 1999 Free Software Foundation, Inc. > 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > Everyone is permitted to copy and distribute verbatim copies > of this license document, but changing it is not allowed. > > [This is the first released version of the Lesser GPL. It also counts > as the successor of the GNU Library Public License, version 2, hence > the version number 2.1.] > > Preamble > > The licenses for most software are designed to take away your > freedom to share and change it. By contrast, the GNU General Public > Licenses are intended to guarantee your freedom to share and change > free software--to make sure the software is free for all its users. > > This license, the Lesser General Public License, applies to some > specially designated software packages--typically libraries--of the > Free Software Foundation and other authors who decide to use it. You > can use it too, but we suggest you first think carefully about whether > this license or the ordinary General Public License is the better > strategy to use in any particular case, based on the explanations below. > > When we speak of free software, we are referring to freedom of use, > not price. Our General Public Licenses are designed to make sure that > you have the freedom to distribute copies of free software (and charge > for this service if you wish); that you receive source code or can get > it if you want it; that you can change the software and use pieces of > it in new free programs; and that you are informed that you can do > these things. > > To protect your rights, we need to make restrictions that forbid > distributors to deny you these rights or to ask you to surrender these > rights. These restrictions translate to certain responsibilities for > you if you distribute copies of the library or if you modify it. > > For example, if you distribute copies of the library, whether gratis > or for a fee, you must give the recipients all the rights that we gave > you. You must make sure that they, too, receive or can get the source > code. If you link other code with the library, you must provide > complete object files to the recipients, so that they can relink them > with the library after making changes to the library and recompiling > it. And you must show them these terms so they know their rights. > > We protect your rights with a two-step method: (1) we copyright the > library, and (2) we offer you this license, which gives you legal > permission to copy, distribute and/or modify the library. > > To protect each distributor, we want to make it very clear that > there is no warranty for the free library. Also, if the library is > modified by someone else and passed on, the recipients should know > that what they have is not the original version, so that the original > author's reputation will not be affected by problems that might be > introduced by others. > > Finally, software patents pose a constant threat to the existence of > any free program. We wish to make sure that a company cannot > effectively restrict the users of a free program by obtaining a > restrictive license from a patent holder. Therefore, we insist that > any patent license obtained for a version of the library must be > consistent with the full freedom of use specified in this license. > > Most GNU software, including some libraries, is covered by the > ordinary GNU General Public License. This license, the GNU Lesser > General Public License, applies to certain designated libraries, and > is quite different from the ordinary General Public License. We use > this license for certain libraries in order to permit linking those > libraries into non-free programs. > > When a program is linked with a library, whether statically or using > a shared library, the combination of the two is legally speaking a > combined work, a derivative of the original library. The ordinary > General Public License therefore permits such linking only if the > entire combination fits its criteria of freedom. The Lesser General > Public License permits more lax criteria for linking other code with > the library. > > We call this license the "Lesser" General Public License because it > does Less to protect the user's freedom than the ordinary General > Public License. It also provides other free software developers Less > of an advantage over competing non-free programs. These disadvantages > are the reason we use the ordinary General Public License for many > libraries. However, the Lesser license provides advantages in certain > special circumstances. > > For example, on rare occasions, there may be a special need to > encourage the widest possible use of a certain library, so that it becomes > a de-facto standard. To achieve this, non-free programs must be > allowed to use the library. A more frequent case is that a free > library does the same job as widely used non-free libraries. In this > case, there is little to gain by limiting the free library to free > software only, so we use the Lesser General Public License. > > In other cases, permission to use a particular library in non-free > programs enables a greater number of people to use a large body of > free software. For example, permission to use the GNU C Library in > non-free programs enables many more people to use the whole GNU > operating system, as well as its variant, the GNU/Linux operating > system. > > Although the Lesser General Public License is Less protective of the > users' freedom, it does ensure that the user of a program that is > linked with the Library has the freedom and the wherewithal to run > that program using a modified version of the Library. > > The precise terms and conditions for copying, distribution and > modification follow. Pay close attention to the difference between a > "work based on the library" and a "work that uses the library". The > former contains code derived from the library, whereas the latter must > be combined with the library in order to run. > > GNU LESSER GENERAL PUBLIC LICENSE > TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION > > 0. This License Agreement applies to any software library or other > program which contains a notice placed by the copyright holder or > other authorized party saying it may be distributed under the terms of > this Lesser General Public License (also called "this License"). > Each licensee is addressed as "you". > > A "library" means a collection of software functions and/or data > prepared so as to be conveniently linked with application programs > (which use some of those functions and data) to form executables. > > The "Library", below, refers to any such software library or work > which has been distributed under these terms. A "work based on the > Library" means either the Library or any derivative work under > copyright law: that is to say, a work containing the Library or a > portion of it, either verbatim or with modifications and/or translated > straightforwardly into another language. (Hereinafter, translation is > included without limitation in the term "modification".) > > "Source code" for a work means the preferred form of the work for > making modifications to it. For a library, complete source code means > all the source code for all modules it contains, plus any associated > interface definition files, plus the scripts used to control compilation > and installation of the library. > > Activities other than copying, distribution and modification are not > covered by this License; they are outside its scope. The act of > running a program using the Library is not restricted, and output from > such a program is covered only if its contents constitute a work based > on the Library (independent of the use of the Library in a tool for > writing it). Whether that is true depends on what the Library does > and what the program that uses the Library does. > > 1. You may copy and distribute verbatim copies of the Library's > complete source code as you receive it, in any medium, provided that > you conspicuously and appropriately publish on each copy an > appropriate copyright notice and disclaimer of warranty; keep intact > all the notices that refer to this License and to the absence of any > warranty; and distribute a copy of this License along with the > Library. > > You may charge a fee for the physical act of transferring a copy, > and you may at your option offer warranty protection in exchange for a > fee. > > 2. You may modify your copy or copies of the Library or any portion > of it, thus forming a work based on the Library, and copy and > distribute such modifications or work under the terms of Section 1 > above, provided that you also meet all of these conditions: > > a) The modified work must itself be a software library. > > b) You must cause the files modified to carry prominent notices > stating that you changed the files and the date of any change. > > c) You must cause the whole of the work to be licensed at no > charge to all third parties under the terms of this License. > > d) If a facility in the modified Library refers to a function or a > table of data to be supplied by an application program that uses > the facility, other than as an argument passed when the facility > is invoked, then you must make a good faith effort to ensure that, > in the event an application does not supply such function or > table, the facility still operates, and performs whatever part of > its purpose remains meaningful. > > (For example, a function in a library to compute square roots has > a purpose that is entirely well-defined independent of the > application. Therefore, Subsection 2d requires that any > application-supplied function or table used by this function must > be optional: if the application does not supply it, the square > root function must still compute square roots.) > > These requirements apply to the modified work as a whole. If > identifiable sections of that work are not derived from the Library, > and can be reasonably considered independent and separate works in > themselves, then this License, and its terms, do not apply to those > sections when you distribute them as separate works. But when you > distribute the same sections as part of a whole which is a work based > on the Library, the distribution of the whole must be on the terms of > this License, whose permissions for other licensees extend to the > entire whole, and thus to each and every part regardless of who wrote > it. > > Thus, it is not the intent of this section to claim rights or contest > your rights to work written entirely by you; rather, the intent is to > exercise the right to control the distribution of derivative or > collective works based on the Library. > > In addition, mere aggregation of another work not based on the Library > with the Library (or with a work based on the Library) on a volume of > a storage or distribution medium does not bring the other work under > the scope of this License. > > 3. You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. To do > this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version 2, > instead of to this License. (If a newer version than version 2 of the > ordinary GNU General Public License has appeared, then you can specify > that version instead if you wish.) Do not make any other change in > these notices. > > Once this change is made in a given copy, it is irreversible for > that copy, so the ordinary GNU General Public License applies to all > subsequent copies and derivative works made from that copy. > > This option is useful when you wish to copy part of the code of > the Library into a program that is not a library. > > 4. You may copy and distribute the Library (or a portion or > derivative of it, under Section 2) in object code or executable form > under the terms of Sections 1 and 2 above provided that you accompany > it with the complete corresponding machine-readable source code, which > must be distributed under the terms of Sections 1 and 2 above on a > medium customarily used for software interchange. > > If distribution of object code is made by offering access to copy > from a designated place, then offering equivalent access to copy the > source code from the same place satisfies the requirement to > distribute the source code, even though third parties are not > compelled to copy the source along with the object code. > > 5. A program that contains no derivative of any portion of the > Library, but is designed to work with the Library by being compiled or > linked with it, is called a "work that uses the Library". Such a > work, in isolation, is not a derivative work of the Library, and > therefore falls outside the scope of this License. > > However, linking a "work that uses the Library" with the Library > creates an executable that is a derivative of the Library (because it > contains portions of the Library), rather than a "work that uses the > library". The executable is therefore covered by this License. > Section 6 states terms for distribution of such executables. > > When a "work that uses the Library" uses material from a header file > that is part of the Library, the object code for the work may be a > derivative work of the Library even though the source code is not. > Whether this is true is especially significant if the work can be > linked without the Library, or if the work is itself a library. The > threshold for this to be true is not precisely defined by law. > > If such an object file uses only numerical parameters, data > structure layouts and accessors, and small macros and small inline > functions (ten lines or less in length), then the use of the object > file is unrestricted, regardless of whether it is legally a derivative > work. (Executables containing this object code plus portions of the > Library will still fall under Section 6.) > > Otherwise, if the work is a derivative of the Library, you may > distribute the object code for the work under the terms of Section 6. > Any executables containing that work also fall under Section 6, > whether or not they are linked directly with the Library itself. > > 6. As an exception to the Sections above, you may also combine or > link a "work that uses the Library" with the Library to produce a > work containing portions of the Library, and distribute that work > under terms of your choice, provided that the terms permit > modification of the work for the customer's own use and reverse > engineering for debugging such modifications. > > You must give prominent notice with each copy of the work that the > Library is used in it and that the Library and its use are covered by > this License. You must supply a copy of this License. If the work > during execution displays copyright notices, you must include the > copyright notice for the Library among them, as well as a reference > directing the user to the copy of this License. Also, you must do one > of these things: > > a) Accompany the work with the complete corresponding > machine-readable source code for the Library including whatever > changes were used in the work (which must be distributed under > Sections 1 and 2 above); and, if the work is an executable linked > with the Library, with the complete machine-readable "work that > uses the Library", as object code and/or source code, so that the > user can modify the Library and then relink to produce a modified > executable containing the modified Library. (It is understood > that the user who changes the contents of definitions files in the > Library will not necessarily be able to recompile the application > to use the modified definitions.) > > b) Use a suitable shared library mechanism for linking with the > Library. A suitable mechanism is one that (1) uses at run time a > copy of the library already present on the user's computer system, > rather than copying library functions into the executable, and (2) > will operate properly with a modified version of the library, if > the user installs one, as long as the modified version is > interface-compatible with the version that the work was made with. > > c) Accompany the work with a written offer, valid for at > least three years, to give the same user the materials > specified in Subsection 6a, above, for a charge no more > than the cost of performing this distribution. > > d) If distribution of the work is made by offering access to copy > from a designated place, offer equivalent access to copy the above > specified materials from the same place. > > e) Verify that the user has already received a copy of these > materials or that you have already sent this user a copy. > > For an executable, the required form of the "work that uses the > Library" must include any data and utility programs needed for > reproducing the executable from it. However, as a special exception, > the materials to be distributed need not include anything that is > normally distributed (in either source or binary form) with the major > components (compiler, kernel, and so on) of the operating system on > which the executable runs, unless that component itself accompanies > the executable. > > It may happen that this requirement contradicts the license > restrictions of other proprietary libraries that do not normally > accompany the operating system. Such a contradiction means you cannot > use both them and the Library together in an executable that you > distribute. > > 7. You may place library facilities that are a work based on the > Library side-by-side in a single library together with other library > facilities not covered by this License, and distribute such a combined > library, provided that the separate distribution of the work based on > the Library and of the other library facilities is otherwise > permitted, and provided that you do these two things: > > a) Accompany the combined library with a copy of the same work > based on the Library, uncombined with any other library > facilities. This must be distributed under the terms of the > Sections above. > > b) Give prominent notice with the combined library of the fact > that part of it is a work based on the Library, and explaining > where to find the accompanying uncombined form of the same work. > > 8. You may not copy, modify, sublicense, link with, or distribute > the Library except as expressly provided under this License. Any > attempt otherwise to copy, modify, sublicense, link with, or > distribute the Library is void, and will automatically terminate your > rights under this License. However, parties who have received copies, > or rights, from you under this License will not have their licenses > terminated so long as such parties remain in full compliance. > > 9. You are not required to accept this License, since you have not > signed it. However, nothing else grants you permission to modify or > distribute the Library or its derivative works. These actions are > prohibited by law if you do not accept this License. Therefore, by > modifying or distributing the Library (or any work based on the > Library), you indicate your acceptance of this License to do so, and > all its terms and conditions for copying, distributing or modifying > the Library or works based on it. > > 10. Each time you redistribute the Library (or any work based on the > Library), the recipient automatically receives a license from the > original licensor to copy, distribute, link with or modify the Library > subject to these terms and conditions. You may not impose any further > restrictions on the recipients' exercise of the rights granted herein. > You are not responsible for enforcing compliance by third parties with > this License. > > 11. If, as a consequence of a court judgment or allegation of patent > infringement or for any other reason (not limited to patent issues), > conditions are imposed on you (whether by court order, agreement or > otherwise) that contradict the conditions of this License, they do not > excuse you from the conditions of this License. If you cannot > distribute so as to satisfy simultaneously your obligations under this > License and any other pertinent obligations, then as a consequence you > may not distribute the Library at all. For example, if a patent > license would not permit royalty-free redistribution of the Library by > all those who receive copies directly or indirectly through you, then > the only way you could satisfy both it and this License would be to > refrain entirely from distribution of the Library. > > If any portion of this section is held invalid or unenforceable under any > particular circumstance, the balance of the section is intended to apply, > and the section as a whole is intended to apply in other circumstances. > > It is not the purpose of this section to induce you to infringe any > patents or other property right claims or to contest validity of any > such claims; this section has the sole purpose of protecting the > integrity of the free software distribution system which is > implemented by public license practices. Many people have made > generous contributions to the wide range of software distributed > through that system in reliance on consistent application of that > system; it is up to the author/donor to decide if he or she is willing > to distribute software through any other system and a licensee cannot > impose that choice. > > This section is intended to make thoroughly clear what is believed to > be a consequence of the rest of this License. > > 12. If the distribution and/or use of the Library is restricted in > certain countries either by patents or by copyrighted interfaces, the > original copyright holder who places the Library under this License may add > an explicit geographical distribution limitation excluding those countries, > so that distribution is permitted only in or among countries not thus > excluded. In such case, this License incorporates the limitation as if > written in the body of this License. > > 13. The Free Software Foundation may publish revised and/or new > versions of the Lesser General Public License from time to time. > Such new versions will be similar in spirit to the present version, > but may differ in detail to address new problems or concerns. > > Each version is given a distinguishing version number. If the Library > specifies a version number of this License which applies to it and > "any later version", you have the option of following the terms and > conditions either of that version or of any later version published by > the Free Software Foundation. If the Library does not specify a > license version number, you may choose any version ever published by > the Free Software Foundation. > > 14. If you wish to incorporate parts of the Library into other free > programs whose distribution conditions are incompatible with these, > write to the author to ask for permission. For software which is > copyrighted by the Free Software Foundation, write to the Free > Software Foundation; we sometimes make exceptions for this. Our > decision will be guided by the two goals of preserving the free status > of all derivatives of our free software and of promoting the sharing > and reuse of software generally. > > NO WARRANTY > > 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO > WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. > EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR > OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY > KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE > IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE > LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME > THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. > > 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN > WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY > AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU > FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR > CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE > LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING > RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A > FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF > SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH > DAMAGES. > > END OF TERMS AND CONDITIONS > > How to Apply These Terms to Your New Libraries > > If you develop a new library, and you want it to be of the greatest > possible use to the public, we recommend making it free software that > everyone can redistribute and change. You can do so by permitting > redistribution under these terms (or, alternatively, under the terms of the > ordinary General Public License). > > To apply these terms, attach the following notices to the library. It is > safest to attach them to the start of each source file to most effectively > convey the exclusion of warranty; and each file should have at least the > "copyright" line and a pointer to where the full notice is found. > > > Copyright (C) > > This library is free software; you can redistribute it and/or > modify it under the terms of the GNU Lesser General Public > License as published by the Free Software Foundation; either > version 2.1 of the License, or (at your option) any later version. > > This library is distributed in the hope that it will be useful, > but WITHOUT ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > Lesser General Public License for more details. > > You should have received a copy of the GNU Lesser General Public > License along with this library; if not, write to the Free Software > Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > > Also add information on how to contact you by electronic and paper mail. > > You should also get your employer (if you work as a programmer) or your > school, if any, to sign a "copyright disclaimer" for the library, if > necessary. Here is a sample; alter the names: > > Yoyodyne, Inc., hereby disclaims all copyright interest in the > library `Frob' (a library for tweaking knobs) written by James Random Hacker. > > , 1 April 1990 > Ty Coon, President of Vice > > That's all there is to it! > ------------------------ end of proposed license ------------------ > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From gjhanna at gmail.com Sun Mar 11 14:21:17 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Mon, 12 Mar 2007 09:21:17 +1300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hi Pavel, We are using RXTX under VMWare server in production, quite satisfactorily. We're using Red Hat Enterprise Server 4, and ... Whatever the "enterprise" VMWare product is. Regards, Greg H > Subject: [Rxtx] RXTX under VMWare server > To: rxtx at qbang.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. [ ... snip ... ] -- Pavel Parkhomenko -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070311/4cebb6f9/attachment-0079.html From gergg at cox.net Sun Mar 11 23:39:19 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 12 Mar 2007 00:39:19 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: <45F4E787.6050502@cox.net> Trent Jarvi wrote: > I can start going through the method interfaces later this week and giving > feedback. I would suggest that the JSR should not be too generic in > nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel > drivers that intend to look like EIA232 ports at the kernel driver level. > > some ideas: > > EIA232PortInterface > TermiosInterface > SerialPortInterface > > Something that differentiates this from thing like USB, I2C, ... which > should not have to deal with legacy serial claiming to be the comm api. I'm going to throw out a suggestion, which I am mostly serious about. What would happen if we took the appropriate bits of the J2ME connector API, and just used that as the new COMM API so that finally JSE and JME had a common foundation for these kinds of things? Gregg Wonderly From ra85551 at gmail.com Mon Mar 12 09:08:37 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Mon, 12 Mar 2007 18:08:37 +0300 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Should any application use the modem, HyperTerminal won't be able to talk to the modem. But it actually can send and receive AT comands, while my application cannot :-( > Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Thansk for the reference. I examined that example and found that there's no significant differences between my read/write implementation and that one, except that SimpleSnuV1 listens for serialEvent's, but not for sake of data retrieval, just for printing them out - I don't know why ;-) > Note that modems could care less what OS is on top. If you are trying to > match new lines to the OS and sending it to the mode for AT commands, > thats probably a mistake. I do send strings to serial port, not to OS, and do try to get answers back. If it is the mistake, what's the right way? > Also it would not hurt to print out the > individual bytes that you are sending to make sure they did not get > mangled along the path. Yeah, I am printing these bytes before doing write, but it means that I only see what I intend to write. How can I ensure that these bytes have gone out of the box and reached my modem? BTW, I found that my send/receive method is complex enough, so I've rewritten it. Please, see the following code and point any mistakes, because I don't know where can they remain yet. private static final int LARGE_TIMEOUT = 15000; private static final int SMALL_TIMEOUT = 500; ... private String sendATCommand(String command, String waitFor, boolean isRegex, boolean isAddCRLF) throws BeaconConnectException { byte[] buffer = new byte[512]; int offset; String result = ""; try { if (waitFor != null) { serialPort.enableReceiveTimeout(LARGE_TIMEOUT); } else { serialPort.enableReceiveTimeout(SMALL_TIMEOUT); } if (command != null) { OutputStream serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } offset = 0; InputStream serialInput = serialPort.getInputStream(); while (serialInput.available() != -1) { int bytesRead = serialInput.read(buffer, offset, buffer.length - offset); if (bytesRead == 0) { break; } offset += bytesRead; result = new String(buffer, 0, offset).trim(); if (waitFor != null) { System.out.println(result); if (isRegex && result.matches(waitFor) || result.contains(waitFor)) { break; } } } } catch (UnsupportedCommOperationException e) { throw new MyException("unsupported operation"); } catch (IOException e) { throw new MytException("serial I/O error"); } return result; } -- Pavel Parkhomenko From clayno at hotpop.com Thu Mar 15 02:47:34 2007 From: clayno at hotpop.com (Christopher Layno) Date: Thu, 15 Mar 2007 16:47:34 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi, we're using the latest release of rxtx (2.1-7r2) for our system that has two applications using the library. one application sends requests to the modem while the other simply checks the modem status. we deployed our system on a pentium machine with red hat linux 9.0 installed. now the problem arises when these two applications try to access the same modem at the same time. one of them will eventually have to throw the PortInUseException as shown below: 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException gnu.io.PortInUseException: root PID = 743 Program = java root PID = 743 Program = java root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) this was expected. what we didn't expect though was that if we repeat the scenario 5 times, always 5 times, the application would also throw a VM error: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4473CD21 Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so Current Java thread: at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) - locked <0x44cfd4c8> (a gnu.io.CommPortIdentifier) at ************ at ************ - locked <0x4476a468> (a **********) at ************ at ************ at ************ at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java :261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages( TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run( TCPTransport.java:701) at java.lang.Thread.run(Thread.java:534) note: i replaced some sensitive data with asterisks our team has looked everywhere on the internet, including your mail archives, for a solution to this problem but to no avail. i really hope you could help us out on this one. thanks in advance! best regards, chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070315/1936460a/attachment-0076.html From tjarvi at qbang.org Fri Mar 16 04:30:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 04:30:25 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: On Thu, 15 Mar 2007, Christopher Layno wrote: > hi, > > we're using the latest release of rxtx (2.1-7r2) for our system that has two > applications using the library. one application sends requests to the modem > while the other simply checks the modem status. we deployed our system on a > pentium machine with red hat linux 9.0 installed. > > now the problem arises when these two applications try to access the same > modem at the same time. one of them will eventually have to throw the > PortInUseException as shown below: > > 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException > gnu.io.PortInUseException: root PID = 743 Program = java root PID = > 743 Program = java root PID = 743 Program = ??? root PID = 743 Program > = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root > PID = 743 Program = ??? root PID = 743 Program = ??? > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > > this was expected. what we didn't expect though was that if we repeat the > scenario 5 times, always 5 times, the application would also throw a VM > error: > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x4473CD21 > Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 > Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so > > Current Java thread: > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) Hi Chris The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. The code is originally by Werner Almesberger. He gave us permission to use it in rxtx. You might look at what has changed since 1998 in his fuser application. Or you can just do like other OSs and do the following in fuserImp.c JNIEXPORT jstring JNICALL Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv *env, jobject obj, jstring arg) { return (*env)->NewStringUTF(env, "Unknown Application"); } It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. -- Trent Jarvi tjarvi at qang.org From Adrien.TOS at ingenico.com Fri Mar 16 05:11:12 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Fri, 16 Mar 2007 12:11:12 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903CBC312@frsnprexc1.usr.ingenico.loc> Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070316/972ab214/attachment-0075.html From joachim at buechse.de Fri Mar 16 05:13:24 2007 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 16 Mar 2007 12:13:24 +0100 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. From tjarvi at qbang.org Fri Mar 16 16:36:29 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 16:36:29 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Fri Mar 16 16:02:23 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 16 Mar 2007 18:02:23 -0400 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Not all platforms are Unix based. Also mixing native library usage and command-line calls is not an elegant solution, IMHO. One or the other, but not both. Andre On 16-Mar-07, at 07:13 , Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is > trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We >> only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From clayno at hotpop.com Sun Mar 18 22:17:28 2007 From: clayno at hotpop.com (Christopher Layno) Date: Mon, 19 Mar 2007 12:17:28 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi everyone, thank you so much for your replies. they were really helpful. anyway, before i sent the email, my team was already implementing a temporary solution by using joachim's suggestion. we invoked a lsof command from our java code although i share the same concern with trent and andre-john about portability issues. that's why i said it's just temporary. my superiors have yet to approve our bug fix. so my question now is this: is recompiling the rxtx source code the only way to solve this problem? because if it's the only solution, then i think my superiors would rather have a new release from the rxtx community itself that fixes this bug(?) rather than have my team recompile the source code. best regards, chris Trent Jarvi wrote: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. ... It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070318/237463b2/attachment-0072.html From tjarvi at qbang.org Mon Mar 19 16:20:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Mar 2007 16:20:52 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: Hi Chris I can compile a new version after the 21st if you do not feel comfortable doing so. Please send me an email reminder off-line then. On Mon, 19 Mar 2007, Christopher Layno wrote: > hi everyone, > > thank you so much for your replies. they were really helpful. > > anyway, before i sent the email, my team was already implementing a > temporary solution by using joachim's suggestion. > we invoked a lsof command from our java code although i share the same > concern with trent and andre-john about > portability issues. that's why i said it's just temporary. my superiors have > yet to approve our bug fix. > > so my question now is this: is recompiling the rxtx source code the only way > to solve this problem? because if it's the only > solution, then i think my superiors would rather have a new release from the > rxtx community itself that fixes this bug(?) > rather than have my team recompile the source code. > > best regards, > > chris > > Trent Jarvi wrote: > > Hi Joachim > > It would be nice to have that functionality but calling the program > introduces too many issues imho. Explaining to someone why rxtx invoked a > rogue lsof does not sound very interesting. > > On Fri, 16 Mar 2007, Joachim Buechse wrote: > > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: > > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. > > _______________________________________________ > Rxtx mailing list > Rxtx 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 Eric.Arseneau at sun.com Tue Mar 20 11:47:33 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Tue, 20 Mar 2007 10:47:33 -0700 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 Message-ID: <46001E35.9040608@sun.com> Anyone have any experience with RXTX working with JDK 6 on other platforms ? From mm at UDel.Edu Tue Mar 20 12:18:29 2007 From: mm at UDel.Edu (Mike Markowski) Date: Tue, 20 Mar 2007 14:18:29 -0400 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 In-Reply-To: <46001E35.9040608@sun.com> References: <46001E35.9040608@sun.com> Message-ID: <46002575.4000306@udel.edu> Eric Arseneau wrote: > Anyone have any experience with RXTX working with JDK 6 on other platforms ? I'm using 32 bit intel, gentoo linux, jdk6 with no problems. My applications only use a serial port, though, nothing on the parallel port. Mike From falko.guderian at gmx.de Wed Mar 21 08:17:35 2007 From: falko.guderian at gmx.de (Falko Guderian) Date: Wed, 21 Mar 2007 15:17:35 +0100 Subject: [Rxtx] RXTX binaries for SH4 Message-ID: <46013E7F.40102@gmx.de> Dear developers, I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no possiblities to compile the source code. Better, I'm not able to do this at the moment. Can you provide me with rxtxSerial.dll (SH4) in the rxtx-2.1-8-testing version? (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) The reason for the testing version is I need custom baud rates. Thanks for help. Kind regards, Falko Guderian From tjarvi at qbang.org Wed Mar 21 21:38:37 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Mar 2007 21:38:37 -0600 (MDT) Subject: [Rxtx] RXTX binaries for SH4 In-Reply-To: <46013E7F.40102@gmx.de> References: <46013E7F.40102@gmx.de> Message-ID: On Wed, 21 Mar 2007, Falko Guderian wrote: > Dear developers, > > I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no > possiblities to compile the source code. Better, I'm not able to do this > at the moment. Can you provide me with rxtxSerial.dll (SH4) in the > rxtx-2.1-8-testing version? > (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) > > The reason for the testing version is I need custom baud rates. > > Thanks for help. > Hi Falko WinCE binary format is not supported by gcc. That makes compiling limited to those familiar with the WinCE tools. I hope someone is able to provide them for you but it is not likely. WinCE has been compiled by others in the past but rxtx.org builds have never included WinCE. There is some information with the source concerning WinCE builds if you decide to do it. We can share your results too if you like. The source in the WinCE has never been updated for the custom baud rate. That would need changes from the main source I presume. If you look at the source, you will note that Michal Hobot created a mini fork in the source to handle wince but it has not been updated for 3 years. -- Trent Jarvi tjarvi at qbang.org From Adrien.TOS at ingenico.com Thu Mar 22 07:08:55 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Thu, 22 Mar 2007 14:08:55 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Hi everybody, Do you have any comments on this issue? Thanks! AT ________________________________ De : Adrien TOS Envoy? : vendredi 16 mars 2007 12:11 ? : 'rxtx at qbang.org' Cc : Adrien TOS Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070322/2306c538/attachment-0068.html From jeremy.reeve at zen.co.uk Mon Mar 19 07:36:04 2007 From: jeremy.reeve at zen.co.uk (Jeremy S. Reeve) Date: Mon, 19 Mar 2007 13:36:04 +0000 Subject: [Rxtx] rxtx failing to compile on Fedora Core 6 Message-ID: <1174311364.21865.6.camel@d9thc> When trying to compile latest source : rxtx-2.1-7r2 I get the following when running configure: ---------------- checking os.version 2.6.18-1.2200.fc5smp WARNING: configure is having a hard time determining which directory contains the file jni_md.h. Edit Makefile and fix the variable JAVANATINC to point to the correct directory. The following options are available: /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/ /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/linux/ If there are more than one option available the first was selected. WARNING: Kernel include files do not match the current kernel configure: creating ./config.status ------------------------ which seems OK checking the resultant Makefile but when attempting to build with gmake install I get the following output : ---------------------- 34 problems (34 warnings)/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/javah -classpath .:/home/jsr/rxtxsrc/rxtx-2.1-7r2:/home/jsr/rxtxsrc/rxtx-2.1-7r2/src:/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/ext/RXTXcomm.jar -d i686-pc-linux-gnu -jni `(for i in CommDriver CommPortEnumerator CommPortIdentifier CommPort CommPortOwnershipListener Configure I2C I2CPortEvent I2CPortEventListener I2CPort LPRPort NoSuchPortException ParallelPortEvent ParallelPortEventListener ParallelPort PortInUseException Raw RawPortEvent RawPortEventListener RawPort RS485 RS485PortEvent RS485PortEventListener RS485Port RXTXCommDriver RXTXPort RXTXVersion SerialPortEvent SerialPortEventListener SerialPort UnsupportedCommOperationException UnSupportedLoggerException Zystem;do \ if grep > /dev/null native.* \( /home/jsr/rxtxsrc/rxtx-2.1-7r2/./src/$i.java; then \ echo gnu.io.$i; \ fi; \ done)` i686-pc-linux-gnu/gnu_io_CommPortIdentifier.h: No such file or directory make: *** [/home/jsr/rxtxsrc/rxtx-2.1-7r2/gnu/io/CommDriver.class] Error 1 ------------------------ Any ideas or pointers? Regards, Jeremy From tjarvi at qbang.org Sat Mar 24 08:12:54 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 Mar 2007 08:12:54 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > From Adrien.TOS at ingenico.com Sat Mar 24 11:53:22 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Sat, 24 Mar 2007 18:53:22 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> I do not have the threshold setting enabled, I have explicitely disabled it with: port_.disableReceiveThreshold(); I have also run the same tests with the threshold setting enabled, but they also fail in the same way as described below. So it seems there is a problem with timeout handling on Win32? ________________________________ From: rxtx-bounces at qbang.org on behalf of Trent Jarvi Sent: Sat 3/24/2007 3:12 PM To: RXTX Developers and Users Subject: Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 8312 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20070324/f9e39c9b/attachment-0066.bin From greg.johnson at manchester.ac.uk Sun Mar 25 13:41:36 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Sun, 25 Mar 2007 21:41:36 +0200 Subject: [Rxtx] Mac intel weirdness Message-ID: Hi folks, I'm trying to get rxtx to work on my macbook pro with a USB-serial dongle on it. I am using the 2.1-8 code from the CVS (though it seems to report itself as 2.1-7: makes it difficult to prove to oneself that the changes have 'taken'! - line 4210 in SerialImp.c, line 40 in RXTXVersion.java) I am trying the 2.1-8 because of horrible lock problems in 2.1-7. However, the serialport closure code seems to be broken - it won't close because it believes the (previously opened!) port doesn't exist. Here is what I'm trying: 0. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "false" 1. Open a port Serialport serialport = (SerialPort) commportidentifier.open ("test",100); 2. Talk to a device ... 3. Close port serialport.close(); 4. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "true" - why is this? 5. Try to reopen port Serialport serialport2 = (SerialPort) commportidentifier.open("test", 100); throws PortInUseException. I've dug around a bit in the source, and it seems the SerialPort.close () should call the CommPortIdentifier.internalClosePort() (line 67 of CommPort.java). However, I crash out with the NoSuchPortException when getPortIdentifier is called. Which seems quite weird to me, seeing as it is called on this - which was create just beforehand. Does anyone know how to fix this? Cheers, greg From knute at frazmtn.com Sat Mar 24 10:32:38 2007 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 24 Mar 2007 09:32:38 -0700 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc>, Message-ID: <4604F036.17833.135298@knute.frazmtn.com> > >The behavior of timeout depends upon the setting of the threshold. Do you >have the threshold setting? > This is the same bug I reported last fall. There was a fellow that sent me an email asking if it had been fixed. I told him I didn't think so. He got somebody to write a fix for him but I have not been able to contact him again for the actual changes. The inaccurate timeout and the failure of blocking when no timeouts are set is a serious bug in my humble opinion and renders the software unusable for my applications. I'd really like to have an alternative to the Sun comm api but there just isn't one that I know of. -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Mar 26 16:17:00 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 26 Mar 2007 16:17:00 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> Message-ID: >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. From ra85551 at gmail.com Tue Mar 27 10:18:36 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Tue, 27 Mar 2007 20:18:36 +0400 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Ultimately I found a solution. At first, that wasn't actually the VMWare + WinXP + RXTX issue, that was WinXP + RXTX issue. But on pure XP it sometimes workes, sometimes not, while under VMWare I had never seen my snippet working at all. SimpleSnuV1.java would not help me, because there is only one line I missed, and SimpleSnuV1.java also doesn't contain it! It is as follows: serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_OUT | SerialPort.FLOWCONTROL_RTSCTS_IN); Thank you for your attention. -- Pavel Parkhomenko From griff at op.pl Wed Mar 28 01:28:19 2007 From: griff at op.pl (griff@op.pl) Date: Wed, 28 Mar 2007 09:28:19 +0200 Subject: [Rxtx] No blocking read on Windows. Message-ID: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/5d07d571/attachment-0063.html -------------- next part -------------- Hi, I have problem that InputStram.read() (SerialPort)?returns -1 instead blocking and waiting for data. I found that this problem was ?known in 2005 : ? >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > >> Hi Trent >> >> Thanks for the fast response. >> Here's a Q&D test program for the blocking read on windows that just >> attempts to read one byte, and prints the resulting byte. On my system it >> returns -1, where I expect that it keeps waiting for data. >> >This isn't happening on Linux so the bug is in src/termios.c.? I'll have >something this weekend to fix that. I'm using RXTX 2.1.7r2 and the problem still is here. Im using Windows XP and java 1.5 disableReciveTimeout() and disableReciveTreshhold() dont help. ? best regards ? Piotr Zielniok From Adrien.TOS at ingenico.com Wed Mar 28 01:40:46 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Wed, 28 Mar 2007 09:40:46 +0200 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903E88880@frsnprexc1.usr.ingenico.loc> Looking at the code, it seems there is no support for infinite timeout? And maybe the count++ < 20 condition is breaking out of the loop too early? The only condition to break out of the loop should either be the timeout has expired or the number of requested bytes has been received. -----Message d'origine----- De : rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] De la part de Trent Jarvi Envoy? : mardi 27 mars 2007 00:17 ? : RXTX Developers and Users Objet : Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From j.kenneth.gentle at acm.org Wed Mar 28 06:44:15 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 28 Mar 2007 08:44:15 -0400 Subject: [Rxtx] No blocking read on Windows. In-Reply-To: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> References: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> Message-ID: <200703281844.l2SIiITW028614@qbang.org> Just another "ME TOO!" - I'm seeing this problem on Windows XP, jre for windows XP/Embedded. I cranked receiveTimeout up to Integer.MAX_INT, but it doesn't seem to wait that long At 03:28 2007-03-28, you wrote: >Hi, >I have problem that InputStram.read() (SerialPort) returns -1 >instead blocking and waiting for data. I found that this problem >was known in 2005 : > > >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > > > >> Hi Trent > >> > >> Thanks for the fast response. > >> Here's a Q&D test program for the blocking read on windows that just > >> attempts to read one byte, and prints the resulting byte. On my system it > >> returns -1, where I expect that it keeps waiting for data. > >> > > >This isn't happening on Linux so the bug is in src/termios.c. I'll have > >something this weekend to fix that. > >I'm using RXTX 2.1.7r2 and the problem still is here. >Im using Windows XP and java 1.5 >disableReciveTimeout() and disableReciveTreshhold() dont help. > >best regards > >Piotr Zielniok > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From greg.johnson at manchester.ac.uk Wed Mar 28 14:43:29 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Wed, 28 Mar 2007 22:43:29 +0200 Subject: [Rxtx] Cannot close and reopen serial port Message-ID: <377F9765-7A9D-4CE9-9176-FFB63A2594F0@manchester.ac.uk> Dear all, It appears I cannot close a port properly: SerialPort serialport = portid.open("myprog",100); // do some stuff, all works fine serialport.close(); // all seems fine but... SerialPort sp2 = portid.open("myprog",100); throws PortInUseException. And when I dig into the rxtx code, I find in CommPort.java, in close(): CommPortIdentifier cp = CommPortIdentifier.getPortIdentifier(this); (line 64 or there abouts) but this throws a NoSuchPortException which is caught but ignored (line 74ish). Can anyone suggest how this could happen: a port that was valid, opened, and used, throws a NSPE when it comes to closing it? I'm pulling my (remaining) hair out over this one! Cheers, greg PS And thanks for RXTX - it's great to have! PPS (21.-7. winxp/osx both, java 1.5) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/c28852fc/attachment-0062.html From rxtx at vrijheidslaan.net Fri Mar 30 16:52:50 2007 From: rxtx at vrijheidslaan.net (Rob) Date: Fri, 30 Mar 2007 22:52:50 -0000 Subject: [Rxtx] Cvs Question Message-ID: <61896.80.126.150.87.1175295162.squirrel@webmail.provalue.nl> Hi There, Im trying to get the latest version to work on mac osx. Problem is that i can't checkout version 2.1.8. Probably my fault but can some one please give me the alternative commands for: [user at myhost]$ export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot [user at myhost]$ cvs login Thanx, Rob From ra85551 at gmail.com Thu Mar 1 03:47:06 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Thu, 1 Mar 2007 13:47:06 +0300 Subject: [Rxtx] enableReceiveTimeout() issue Message-ID: Hello, world! I found a limitation of 16300 ms for CommPort's enableReceiveTimeout() method, while in original javax.comm docs there are no any references to that. Is that a bug or feature? I actually need longer timeouts sometimees. -- Pavel Parkhomenko From lyon at docjava.com Thu Mar 1 07:54:17 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 01 Mar 2007 09:54:17 -0500 Subject: [Rxtx] parametric singleton design pattern In-Reply-To: References: <22d55aea0702081207q5e7f6785l352d498d6f5f9fb1@mail.gmail.com> <22d55aea0702100034o3bcf42f3j1d1a6257029a67b0@mail.gmail.com> Message-ID: Hi All, I have been thinking about the use of a design pattern to cache resources that are consumed by processes. Toward that end, I have arrived at a parametric singleton design pattern, which I mentioned on this list some time ago. The idea has been published at: http://www.jot.fm/issues/issue_2007_03/column2 I can't help but think that there should be an API available for dealing with the tracking of serial port usage. Perhaps it is a kind of resource manager called the: SerialPortManager basic prototypes already exist in this vain. See, for example: http://www.ce.rit.edu/research/projects/2005_fall/rt_poolsystem/doc/PoolMon/SerialPortManager.html http://www.eventhelix.com/RealtimeMantra/PatternCatalog/serial_port_design_pattern.htm And others shown by a google search on "SerialPortManager" Cheers! - Doug From Eric.Arseneau at sun.com Thu Mar 1 10:15:03 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:15:03 -0800 Subject: [Rxtx] Any known Java 6 issues with RXTX 2.1-7r2 ? Message-ID: <45E70A17.1060206@sun.com> I just did a test on a recent build of Solaris 11 x86 and it seems that I can connect to my serial device fine when Java 5 is the default, but when Java 6 is the default, no go. Any information ? From Eric.Arseneau at sun.com Thu Mar 1 10:19:58 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:19:58 -0800 Subject: [Rxtx] Mac OS X and missing data Message-ID: <45E70B3E.7040908@sun.com> We have a device which is USB based but presents itself as a serial port to a machine. On my MacBook Pro I can get excellent throughput if I get my device to send data as quickly as possible. On the desktop side, if I do an type of disk IO to log the data I get, I end up with some missing data at some point. I hooked up a USB analyzer and did confirm that all the data is sent as expected to the desktop from the device. I found a work around for this, buffer the data in memory and only write the data out when I've received it all. However, when the same code and same device is attempted on a co-workers MacBook Pro (same hardware specs), I get errors and must slow down dramatically the device side's sending of data. Any ideas/recommendations on what I can do to get rid of this error ? From what I can tell, it seems that RXTX is not able to wake up to the interrupts coming in indicating data is ready, quickly enough, is there anything I can do ? From chinkaiw at hotmail.com Fri Mar 2 00:57:43 2007 From: chinkaiw at hotmail.com (Wang Chinkai) Date: Fri, 02 Mar 2007 07:57:43 +0000 Subject: [Rxtx] dynamic detect rs232 port Message-ID: Hi all I have a question about detecting rs232 port dynamicly. I have to aceess some port and detect rs232 port at the same time. Some usb device simulates rs232 port , and I can not know what the port name it gets until it connects,so I have to detect it dynamic,but I have to access another rs232 device at the same time. I found a problem. If I use CommPortIdentifier.getPortIdentifiers() to get new port list , and the other rs232 access function will not close port correctly. So , How can I solve it . Thanks. _________________________________________________________________ ?? 2GB ???? Windows Live Mail ????????????? http://ideas.live.com/programpage.aspx?versionid=5d21c51a-b161-4314-9b0e-4911fb2b2e6d From eu259473 at tele2.it Fri Mar 2 06:16:40 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 02 Mar 2007 14:16:40 +0100 Subject: [Rxtx] rxtx on HP tru 64 unix Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070302/706c7a70/attachment-0090.html From tjarvi at qbang.org Fri Mar 2 08:39:33 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 08:39:33 -0700 (MST) Subject: [Rxtx] rxtx on HP tru 64 unix In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, "Giuseppe Marchese" wrote: > Hi > > I try to install rxtx on hp tru 64 but make fails, > There are somebody that do the same and work. > > > Sorry for may english! > > Hi Giuseppe Could you provide a log of the failure? script ./configure make # use gnu make exit The information will be in the typescript created. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 2 19:56:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 19:56:52 -0700 (MST) Subject: [Rxtx] dynamic detect rs232 port In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, Wang Chinkai wrote: > Hi all > > I have a question about detecting rs232 port dynamicly. > > I have to aceess some port and detect rs232 port at the same time. > Some usb device simulates rs232 port , and I can not know > what the port name it gets until it connects,so I have to detect it > dynamic,but I have to access > another rs232 device at the same time. > > I found a problem. Hi Wang This is a known problem. The code is braindead there. In fact there needs to be events even in a rudamentary way when you add a usb dongle. I'm burried in tasks not far from rxtx but not in rxtx. I can't get to the problem but we would accept patches if you dig into it. [I'm getting to the license question earlier too; I don't have another 10%] -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Fri Mar 2 23:19:01 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 01:19:01 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Hi, Under ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable USB -> serial converter(using virtual com port drivers), with using example code pretty much straight out of http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port opens fine, enumerations all work, etc. My application calls for a large amount of data to be transferred in a short amount of time at 2,000,000 baud. My hardware sends approximately 15,232 bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL converter work fine, and the application works using C++. In C++, I do a hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); to open the port, and a boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); to read the port. The variable buffer fills with the 15238 bytes, and returns. If I do a resultz = is.read(cbuf,0,15238); in java with RXTX where is = new BufferedReader(new InputStreamReader(port.getInputStream())); and where resultz is an int, and cbuf is a char [] cbuf, resultz gets EXACTLY 3968 bytes the first time called. If I call it multiple times, I get roughly 11k total(less than what is sent), never more than the 3968 bytes per is.read() call. My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 bytes. I've played with inputbuffersize, receive threshold, receivetimeout, and so on. The FTDI virtual com port drivers that I'm using are rock solid, and have had zero problems with them using a variety of applications, some of my own, some professionally written, etc. No flow control is used anyplace, no RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. No exceptions are being thrown. What am I doing wrong, and what I can adjust to receive the full 15k bytes in one single read? Thanks! Keith From Eric.Arseneau at sun.com Fri Mar 2 23:32:07 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Fri, 02 Mar 2007 22:32:07 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <45E91667.20501@sun.com> This is the same type of thing that is happening to me on Mac OS X and does not seem to behave the same on different machines. I posted a day or two ago on this with subject "Mac OS X and missing data". Would love to hear if there is a solution to this :) From tjarvi at qbang.org Sat Mar 3 10:54:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 10:54:17 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > Hi, > > Under > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable > USB -> serial converter(using virtual com port drivers), with using example > code pretty much straight out of > http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port > opens fine, enumerations all work, etc. > > My application calls for a large amount of data to be transferred in a short > amount of time at 2,000,000 baud. My hardware sends approximately 15,232 > bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL > converter work fine, and the application works using C++. > > In C++, I do a > > hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, > OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); > > to open the port, and a > > boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); > > to read the port. > > The variable buffer fills with the 15238 bytes, and returns. > > If I do a > > resultz = is.read(cbuf,0,15238); in java with RXTX > > where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > > and where resultz is an int, and cbuf is a char [] cbuf, resultz gets > EXACTLY 3968 bytes the first time called. If I call it multiple times, I get > roughly 11k total(less than what is sent), never more than the 3968 bytes > per is.read() call. > > My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 > bytes. > > I've played with inputbuffersize, receive threshold, receivetimeout, and so > on. The FTDI virtual com port drivers that I'm using are rock solid, and > have had zero problems with them using a variety of applications, some of my > own, some professionally written, etc. No flow control is used anyplace, no > RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. > > No exceptions are being thrown. > > What am I doing wrong, and what I can adjust to receive the full 15k bytes > in one single read? > > Thanks! > Hi Keith I would expect a 20 meg application is going to have different behavior with the OS than a smaller application with respect to the kernel memory managment, schedualing, ... Something subtle could be causing problems. With respect to the recieve timeout and threshold, if you set the timeout to zero and the threshold to the size of data you expect, read should not return until it get that data. You may try with a stand alone application that tests just that with the C/C++ API. If the read is returning with less data when tested for short reads, you have found a bug in the device driver more than likely. The USB dongle vendor would probably be interested in knowing about this. As mentioned, these devices are getting very good; almost bug free. I suspect you found a bug though if you did use the threshold and timeout properly. The missing data is typical when not using flow control. When the OS buffering fills, the hardware will start dropping bytes. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:38:52 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:38:52 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> update: I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now instead of 3968. This makes sense. 128 bytes of overhead + 3968 bytes of data = 4096 transfer size 32 bytes of overhead + 992 bytes of data = 1024 transfer size. 1/4 the data = 1/4 the overhead. I rearranged my reading like so: resultz = is.read(cbuf,0,3968); resultz = is.read(cbuf,3968,3968); resultz = is.read(cbuf,7936,3968); while (!(is.ready())); // wait for ready resultz = is.read(cbuf,11904,3334); and this grabs 15,238 bytes total. BUT, I still have the quandry of the screwed up multi-bytes. I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. Approx 8% of the data. The bad bytes always seem to take the flavor of 0x2018, 0x2019, x2022, x2030, x201d. Are these maybe errors and I don't know what they enumerate to? I still can't believe some other layer isn't handling putting those bytes together all in one stream for me. Thanks Keith ----- Original Message ----- From: "Keith" To: "Bob Jacobsen" ; "RXTX Developers and Users" Sent: Saturday, March 03, 2007 11:26 AM Subject: Re: [Rxtx] is.read() only returning 3968 bytes > Bob, > > > Interesting numerical coincidence is that (max USB transfer) - (what > > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > > needed to transfer that much data. > > I was thinking along the same lines. I don't know USB well, but I do know > that those numbers were close enough to warrant investigating the > relationship between them. > > > I think what you're seeing is the internal buffering of the USB data > > stream. You'll need some form of higher-level buffering to smooth > > that out. > > Shouldn't the InputStreamReader() and BufferedReader() provide this type of > buffering? Isn't that the idea behind those? > > > All hypotheses need to be tested. In this case, a test would be to > > check for missing data. If this idea is right, you'll get _all_ the > > data, but you won't be missing characters. > > I did start looking at the data. -- I'm getting weird results. > > I tried this: > > loopzz = 0; > > for (looptwo = 0; looptwo < 100000; looptwo++) { > while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > > }} > > So I'm reading one character at a time. The good news is that loopzz is > exactly 15238 at the end of the routine, which is perfectly correct. I > picked looptwo value out of thin air. > > The weird results come in terms of the values, the data isn't correct at > least in one case. Look here: > > 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > > This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). > But the 0x89 was replaced by 0x2030. Why the heck would the returned value > be 0x2030?? Why is the returned byte completely out of range? Why the > multibyte return? > > From InputStream in the API: > > read > public abstract int read() > throws IOExceptionReads the next byte of data from the > input stream. The value byte is returned as an int in the range 0 to 255. If > no byte is available because the end of the stream has been reached, the > value -1 is returned. This method blocks until input data is available, the > end of the stream is detected, or an exception is thrown. > Value should be 0-255. > > > In my application time is really critical, reading 1 byte at a time is > probably not going to work. > > Thanks Eric & Bob for looking at this. > > Keith > From tjarvi at qbang.org Sat Mar 3 12:52:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 12:52:27 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > update: > > I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now > instead of 3968. > > This makes sense. > > 128 bytes of overhead + 3968 bytes of data = 4096 transfer size > 32 bytes of overhead + 992 bytes of data = 1024 transfer size. > > 1/4 the data = 1/4 the overhead. > > I rearranged my reading like so: > > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. > Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? > > I still can't believe some other layer isn't handling putting those bytes > together all in one stream for me. > The layer for this in Serial land is flow control. Software and hardware flow control prevent the overruns you observe. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:54:41 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:54:41 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <001a01c75dcd$c8802a70$6600a8c0@jbh757ktruws7g> Trent, Thanks for taking the time to reply. > I would expect a 20 meg application is going to have different behavior > with the OS than a smaller application with respect to the kernel memory > managment, schedualing, ... Something subtle could be causing problems. Well, at least I know the VCP drivers, the OS, etc can handle 2mbps reliably. Without hiccuping or dropping bytes. The C++ code works reliably without flow control. > The missing data is typical when not using flow control. When the OS > buffering fills, the hardware will start dropping bytes. I'm actually not getting MISSING data, I'm getting CORRUPTED data. If you look at my most recent post, I'm getting these bad bytes in place of the correct values: 0x2018, 0x2019, x2022, x2030, x201d. Why would is.read() return values not in the range of 0-255 ? Thanks. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 08:59:14 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 07:59:14 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: At 1:19 AM -0500 3/3/07, Keith wrote: >If I do a > >resultz = is.read(cbuf,0,15238); in java with RXTX > >where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > >and where resultz is an int, and cbuf is a char [] cbuf, resultz gets >EXACTLY 3968 bytes the first time called. If I call it multiple times, I get >roughly 11k total(less than what is sent), never more than the 3968 bytes >per is.read() call. > >My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 >bytes. Interesting numerical coincidence is that (max USB transfer) - (what you get) = 4096-3968 = 128 bytes is (almost) the size of the headers needed to transfer that much data. I think what you're seeing is the internal buffering of the USB data stream. You'll need some form of higher-level buffering to smooth that out. All hypotheses need to be tested. In this case, a test would be to check for missing data. If this idea is right, you'll get _all_ the data, but you won't be missing characters. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 09:26:14 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 11:26:14 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Bob, > Interesting numerical coincidence is that (max USB transfer) - (what > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > needed to transfer that much data. I was thinking along the same lines. I don't know USB well, but I do know that those numbers were close enough to warrant investigating the relationship between them. > I think what you're seeing is the internal buffering of the USB data > stream. You'll need some form of higher-level buffering to smooth > that out. Shouldn't the InputStreamReader() and BufferedReader() provide this type of buffering? Isn't that the idea behind those? > All hypotheses need to be tested. In this case, a test would be to > check for missing data. If this idea is right, you'll get _all_ the > data, but you won't be missing characters. I did start looking at the data. -- I'm getting weird results. I tried this: loopzz = 0; for (looptwo = 0; looptwo < 100000; looptwo++) { while (is.ready()) { cbuf[loopzz] = (char) is.read(); loopzz++; }} So I'm reading one character at a time. The good news is that loopzz is exactly 15238 at the end of the routine, which is perfectly correct. I picked looptwo value out of thin air. The weird results come in terms of the values, the data isn't correct at least in one case. Look here: 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). But the 0x89 was replaced by 0x2030. Why the heck would the returned value be 0x2030?? Why is the returned byte completely out of range? Why the multibyte return? >From InputStream in the API: read public abstract int read() throws IOExceptionReads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown. Value should be 0-255. In my application time is really critical, reading 1 byte at a time is probably not going to work. Thanks Eric & Bob for looking at this. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 14:44:50 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 13:44:50 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: Java's "char" type is Unicode. I think what you're seeing is a bug in the byte -> Unicode translation. 0x2018, 0x2019 are the curly open and close quotes. There used to be (and might still be) bugs in the conversion of these in a couple of libc versions. Some of the ASCII -> ISO and ISO -> ASCII routines were a little over-ambitious with respect to handling the open and close quotes, and tried to convert them to the "curly" form inappropriately. Try _not_ casting it to char. Bob At 11:26 AM -0500 3/3/07, Keith wrote: >Bob, > >> Interesting numerical coincidence is that (max USB transfer) - (what >> you get) = 4096-3968 = 128 bytes is (almost) the size of the headers >> needed to transfer that much data. > >I was thinking along the same lines. I don't know USB well, but I do know >that those numbers were close enough to warrant investigating the >relationship between them. > >> I think what you're seeing is the internal buffering of the USB data >> stream. You'll need some form of higher-level buffering to smooth >> that out. > >Shouldn't the InputStreamReader() and BufferedReader() provide this type of >buffering? Isn't that the idea behind those? > >> All hypotheses need to be tested. In this case, a test would be to >> check for missing data. If this idea is right, you'll get _all_ the >> data, but you won't be missing characters. > >I did start looking at the data. -- I'm getting weird results. > >I tried this: > >loopzz = 0; > >for (looptwo = 0; looptwo < 100000; looptwo++) { >while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > >}} > >So I'm reading one character at a time. The good news is that loopzz is >exactly 15238 at the end of the routine, which is perfectly correct. I >picked looptwo value out of thin air. > >The weird results come in terms of the values, the data isn't correct at >least in one case. Look here: > >0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > >This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). >But the 0x89 was replaced by 0x2030. Why the heck would the returned value >be 0x2030?? Why is the returned byte completely out of range? Why the >multibyte return? > >>From InputStream in the API: > >read >public abstract int read() > throws IOExceptionReads the next byte of data from the >input stream. The value byte is returned as an int in the range 0 to 255. If >no byte is available because the end of the stream has been reached, the >value -1 is returned. This method blocks until input data is available, the >end of the stream is detected, or an exception is thrown. >Value should be 0-255. > > >In my application time is really critical, reading 1 byte at a time is >probably not going to work. > >Thanks Eric & Bob for looking at this. > >Keith > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 15:10:11 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 17:10:11 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Bob said ..... > Java's "char" type is Unicode. I think what you're seeing is a bug > in the byte -> Unicode translation. Bob -- I think you hit the nail on the head. I was just coming to the same realization here. I knew that something funny was going on because the same bytes always got "corrupted." I'm pretty sure its in the InputStreamReader() functionality where the conversion junk is happening. Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. I don't know if simply changing the cast is going to work. Since the conversion is happening upstream (pun intended), I don't think my cast is doing this. Also I think the compiler forced me to use the cast. I'm still playing around, and I'll report back once I nail it down. Thanks!! Keith From tjarvi at qbang.org Sat Mar 3 15:59:46 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 15:59:46 -0700 (MST) Subject: [Rxtx] Win64 rxtx Testers? Message-ID: I have compiled win64 binaries of rxtx. Are there any users interested in testing them? If so, I'll look into putting them on the web site. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Mar 3 15:35:06 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 14:35:06 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: Because of this and similar problems, JMRI does all it's serial IO using +only+ byte values. It's a but of a pain, as Java wants to go to char and int types a little too aggressively, but it does solve the "uncontrolled conversions" problems. Bob At 5:10 PM -0500 3/3/07, Keith wrote: >Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > >Bob -- I think you hit the nail on the head. > >I was just coming to the same realization here. I knew that something funny >was going on because the same bytes always got "corrupted." > >I'm pretty sure its in the InputStreamReader() functionality where the >conversion junk is happening. > >Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > >I don't know if simply changing the cast is going to work. Since the >conversion is happening upstream (pun intended), I don't think my cast is >doing this. Also I think the compiler forced me to use the cast. -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mark at mdsh.com Sun Mar 4 11:01:33 2007 From: mark at mdsh.com (Mark Himsley) Date: Sun, 04 Mar 2007 18:01:33 +0000 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: <5C01AC72C200388815C04982@bedroom.mdsh.local> On 03 March 2007 14:38 -0500 Keith wrote: > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT > consistent. Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? It looks like you need to use DataInputStream and DataOutputStream. -- Mark Himsley From tjarvi at qbang.org Sun Mar 4 11:35:08 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 11:35:08 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" > > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > > * Line #21 - Not sure if you need a (TM) mark for > the term "Sun" > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > OK. I'm going through this today. Some groups ask if rxtx could be under their license also. I think this is a good example of why I resist multiple licenses and focus on why the current license may not be usable by them. The RXTX project is a convergence of hobby and commercial interests. I happen to do both right now. The problem with licensing is we have to stay on top of them as they change. Clearly, adding more licenses will not make this easier. I'm acting as the hobby person today. RXTX always favors the hobby people. But as we move forward, I'm going to need to bring this to lawyers at work and explain to them what is going on. Others here may have to do this also. I don't anticipate problems or unexpected changes. The goal is a consistant, comprehendable and usable license as close to what we have now as possible. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 14:52:10 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 14:52:10 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (1/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: I'm breaking this into two parts. I expect the second part will need more attention. Comments first, then the changed material below. On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > Thanks > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. OK. RXTX for consitent use. java should not be capitalized because it does not only mean Sun [TM] Java [TM]. An example of this not meaning Java is when people use RXTX with GCJ. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". There are not any contributors that are in all of RXTX yet but I did update the comment to try to reflect the current situation without making it a nightmare to maintain. I looked to see how the Linux kernel does it as a reference point. > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" The URL can be problematic. I have done so below with a time reference. GNU does not provide version information in their URLS. I picture this being a problem when the version 3 comes out. > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > This will be corrected when the copy is updated to the version linked below. ---------------- begin proposed material involved -------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. ----------------- end proposed material involved -------------------- I'll be looking at the linking issue again next. That should be all that remains other than including the 2.1 version. Let me know if you have problems with anything here. I do not want to dilute the material I post next with these housekeeping tasks. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 16:08:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 16:08:36 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: For those that are wondering what is going on here, this next bit is the meat of the changes. We agreed a long time ago to put this disclaimer in. We did a so so job. It was in rxtx 2.0, not well written, ... So some groups using rxtx that would like to ship rxtx so users don't need to download, install, go to the mail-list to find why it failed, ... Then their legal teams tell them section 5 paragraph 2 is a show stopper. That was never the intent. Now going through what remains... > and might need a (TM) suffix to make Sun happy. Added disclaimer at the ended 'all trademarks belong...' > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. OK. As you can see I was trying to adjust GNU text there for the LGPL. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. used dynamically linked terminology. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". I tried to address this more upfront with an intent statement. Let me know if you have problems with it. I also tried to make it a little more clear what was derived from the GNU solution by moving the link location closer to GNU's suggestion. > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > Thats the intent. Here is the combined fixes. Note that only the material in /*-- --*/ is being touched. The new GPL license is there but unmodified. ------------------------ begin proposed new license ------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. | | An executable that contains no derivative of any portion of RXTX, but | is designed to work with RXTX by being dynamically linked with it, | is considered a "work that uses the Library" subject to the terms and | conditions of the GNU Lesser General Public License. | | The following has been added to the RXTX License to remove | any confusion about linking to RXTX. We want to allow in part what | section 5, paragraph 2 of the LGPL does not permit in the special | case of linking over a controlled interface. The intent is to add a | Java Specification Request or standards body defined interface in the | future as another exception but one is not currently available. | | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface | | As a special exception, the copyright holders of RXTX give you | permission to link RXTX with independent modules that communicate with | RXTX solely through the Sun Microsytems CommAPI interface version 2, | regardless of the license terms of these independent modules, and to copy | and distribute the resulting combined work under terms of your choice, | provided that every copy of the combined work is accompanied by a complete | copy of the source code of RXTX (the version of RXTX used to produce the | combined work), being distributed under the terms of the GNU Lesser General | Public License plus this exception. An independent module is a | module which is not derived from or based on RXTX. | | Note that people who make modified versions of RXTX are not obligated | to grant this special exception for their modified versions; it is | their choice whether to do so. The GNU Lesser General Public License | gives permission to release a modified version without this exception; this | exception also makes it possible to release a modified version which | carries forward this exception. | | You should have received a copy of the GNU Lesser General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA | All trademarks belong to their respective owners. --------------------------------------------------------------------------*/ The original GNU Lesser General Public License Follows. GNU LESSER GENERAL PUBLIC LICENSE Version 2.1, February 1999 Copyright (C) 1991, 1999 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. [This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence the version number 2.1.] Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This license, the Lesser General Public License, applies to some specially designated software packages--typically libraries--of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below. When we speak of free software, we are referring to freedom of use, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish); that you receive source code or can get it if you want it; that you can change the software and use pieces of it in new free programs; and that you are informed that you can do these things. To protect your rights, we need to make restrictions that forbid distributors to deny you these rights or to ask you to surrender these rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library or if you modify it. For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights. We protect your rights with a two-step method: (1) we copyright the library, and (2) we offer you this license, which gives you legal permission to copy, distribute and/or modify the library. To protect each distributor, we want to make it very clear that there is no warranty for the free library. Also, if the library is modified by someone else and passed on, the recipients should know that what they have is not the original version, so that the original author's reputation will not be affected by problems that might be introduced by others. Finally, software patents pose a constant threat to the existence of any free program. We wish to make sure that a company cannot effectively restrict the users of a free program by obtaining a restrictive license from a patent holder. Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license. Most GNU software, including some libraries, is covered by the ordinary GNU General Public License. This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs. When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library. We call this license the "Lesser" General Public License because it does Less to protect the user's freedom than the ordinary General Public License. It also provides other free software developers Less of an advantage over competing non-free programs. These disadvantages are the reason we use the ordinary General Public License for many libraries. However, the Lesser license provides advantages in certain special circumstances. For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License. In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software. For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU operating system, as well as its variant, the GNU/Linux operating system. Although the Lesser General Public License is Less protective of the users' freedom, it does ensure that the user of a program that is linked with the Library has the freedom and the wherewithal to run that program using a modified version of the Library. The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, whereas the latter must be combined with the library in order to run. GNU LESSER GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License Agreement applies to any software library or other program which contains a notice placed by the copyright holder or other authorized party saying it may be distributed under the terms of this Lesser General Public License (also called "this License"). Each licensee is addressed as "you". A "library" means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables. The "Library", below, refers to any such software library or work which has been distributed under these terms. A "work based on the Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term "modification".) "Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library. Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does. 1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) The modified work must itself be a software library. b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change. c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License. d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful. (For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library. In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. 4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange. If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code. 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables. When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law. If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.) Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself. 6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications. You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things: a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.) b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. c) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution. d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place. e) Verify that the user has already received a copy of these materials or that you have already sent this user a copy. For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute. 7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things: a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above. b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work. 8. You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 9. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Library (or any work based on the Library), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Library or works based on it. 10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties with this License. 11. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply, and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 12. If the distribution and/or use of the Library is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Library under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 13. The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation. 14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Libraries If you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the ordinary General Public License). To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Also add information on how to contact you by electronic and paper mail. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the library, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the library `Frob' (a library for tweaking knobs) written by James Random Hacker. , 1 April 1990 Ty Coon, President of Vice That's all there is to it! ------------------------ end of proposed license ------------------ -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sun Mar 4 16:26:04 2007 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 04 Mar 2007 17:26:04 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <45EB558C.3010609@cox.net> Bob Jacobsen wrote: > Because of this and similar problems, JMRI does all it's serial IO > using +only+ byte values. It's a but of a pain, as Java wants to go > to char and int types a little too aggressively, but it does solve > the "uncontrolled conversions" problems. Anytime that you are reading bytes of data that is not printable, unicode text, in Java, you really need to stay away from the Readers. Use input stream only, or you will see unicode valued byte groups converted to unicode "char" values. Gregg Wonderly From joachim at buechse.de Mon Mar 5 04:23:48 2007 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 5 Mar 2007 12:23:48 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> The behaviour is exactly what you asked for in you code. is = new BufferedReader(new InputStreamReader(port.getInputStream())); Readers return Text (ie unicode chars) not bytes. You instantiate the InputStreamReader without saying which charset you want, which means "platform default". As this is on Windows, it will convert Windows characters to equivalent unicode characters. If you want to read bytes, read bytes not Text. Reading bytes is done with InputStream and BufferedInputStream. BTW: The InputStream and Reader methods that read arrays are not guarenteed to fill up the array. You always have to check what you really got, and advance your index accordingly. A typical "read up to 32k" method looks like this: InputStream is= ... // -- determine the max buffer size int len= is.available(); if (len == 0) { len= 32 * 1024; } // -- read all available data byte[] buffer= new byte[len]; int pos= 0; int read; do { read= is.read(buffer, pos, buffer.length - pos); pos= pos + read; } while (read != -1 && pos < buffer.length); Best regards, Joachim --- Joachim B?chse Phone: +41 44 500 2604 Buechse Consulting Hadlaubsteig 2 CH-8006 Z?rich On 03.03.2007, at 23:10, Keith wrote: > Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > > Bob -- I think you hit the nail on the head. > > I was just coming to the same realization here. I knew that > something funny > was going on because the same bytes always got "corrupted." > > I'm pretty sure its in the InputStreamReader() functionality where the > conversion junk is happening. > > Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > > I don't know if simply changing the cast is going to work. Since the > conversion is happening upstream (pun intended), I don't think my > cast is > doing this. Also I think the compiler forced me to use the cast. > > I'm still playing around, and I'll report back once I nail it down. > > Thanks!! > > Keith > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Mon Mar 5 07:25:46 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 05 Mar 2007 08:25:46 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> Message-ID: <45EC286A.8060608@cox.net> Joachim Buechse wrote: > BTW: The InputStream and Reader methods that read arrays are not > guarenteed to fill up the array. You always have to check what you > really got, and advance your index accordingly. A typical "read up to > 32k" method looks like this: > > InputStream is= ... > // -- determine the max buffer size > int len= is.available(); > if (len == 0) { > len= 32 * 1024; > } > // -- read all available data > byte[] buffer= new byte[len]; > int pos= 0; > int read; > do { > read= is.read(buffer, pos, buffer.length - pos); > pos= pos + read; > } while (read != -1 && pos < buffer.length); > My preferred structure is. byte arr[ len ]; int cnt; int off = 0; while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { off += cnt; } This keeps you from adding -1 to pos when the read returns -1. It also skips out when the read is 0 bytes which, is not a described EOF in InputStream java docs, but is a condition I want to be aware of. Gregg Wonderly From joachim at buechse.de Tue Mar 6 02:52:58 2007 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 6 Mar 2007 10:52:58 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <45EC286A.8060608@cox.net> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: The code I copied was from a file resource reader, it shouldn't really be applied to networking/external IO code. Mea culpa. However aborting when you get 0 from read is not always what you want either (you kind of indicated that already). Some unix java implementations will return 0 if the kernel read was aborted with EINTER, which is rarely the point where you want to abort your read - at least not without further checks. A "complete" solution always depends on the events you need to handle and the time the total read could take in reality. In some cases it's worth checking Thread.isInterrupted() in the loop, some code re-loops on 0 but only a limited number of times, some check a total timeout limit, etc... Best regards, Joachim On 05.03.2007, at 15:25, Gregg Wonderly wrote: > My preferred structure is. > > byte arr[ len ]; > int cnt; > int off = 0; > while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { > off += cnt; > } > > This keeps you from adding -1 to pos when the read returns -1. It > also skips > out when the read is 0 bytes which, is not a described EOF in > InputStream java > docs, but is a condition I want to be aware of. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Mar 6 14:47:44 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 Mar 2007 14:47:44 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: Just FYI, rxtx will usually not break out on EINTER. The code in the native library usually does something close to this: do { read(...) } while ( !done && errno==EINTR ); Obviously there is a little more involved but it will retry on EINTER if not done. On Tue, 6 Mar 2007, Joachim Buechse wrote: > The code I copied was from a file resource reader, it shouldn't > really be applied to networking/external IO code. Mea culpa. > > However aborting when you get 0 from read is not always what you want > either (you kind of indicated that already). Some unix java > implementations will return 0 if the kernel read was aborted with > EINTER, which is rarely the point where you want to abort your read - > at least not without further checks. A "complete" solution always > depends on the events you need to handle and the time the total read > could take in reality. In some cases it's worth checking > Thread.isInterrupted() in the loop, some code re-loops on 0 but only > a limited number of times, some check a total timeout limit, etc... > > Best regards, > Joachim > > On 05.03.2007, at 15:25, Gregg Wonderly wrote: >> My preferred structure is. >> >> byte arr[ len ]; >> int cnt; >> int off = 0; >> while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { >> off += cnt; >> } >> >> This keeps you from adding -1 to pos when the read returns -1. It >> also skips >> out when the read is 0 bytes which, is not a described EOF in >> InputStream java >> docs, but is a condition I want to be aware of. >> >> Gregg Wonderly >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 gjhanna at gmail.com Thu Mar 8 13:42:52 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Fri, 9 Mar 2007 09:42:52 +1300 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? Message-ID: I've just struck an issue using rxtx in a multi-threaded environment: If I have 3 threads trying to open *the same* comm-port I get a deadlock in CommPortIdentifier.open If I have just 2, it works fine - I get a PortInUseException which is nice and I can handle it. The 3 thread->deadlock thing is causing me issues. (Sample code below). This is from the java thread-dump Found one Java-level deadlock: ============================= "Thread-2": waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object ), which is held by "Thread-1" "Thread-1": waiting to lock monitor 0x0003e9cc (object 0x2450e108, a gnu.io.CommPortIdentifier), which is held by "Thread-2" Java stack information for the threads listed above: =================================================== "Thread-2": at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:329) - waiting to lock <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) "Thread-1": at java.lang.Object.wait(Native Method) - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) - locked <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) (Apart from this, rxtx is working fantastically for us). I'm thinking I'll have to implement some sort of locking mechanism that *doesn't* use java synchronization to prevent this situation. (Which doesn't sound like a good idea to me). Any ideas? Thanks, Greg Hanna ============= RXTXLockTest.java ======================================== import gnu.io.CommPort; import gnu.io.CommPortIdentifier; /** * @author Greg Hanna * Minimal code to create a deadlock with rxtx in multithreaded open */ public class RXTXLockTest { public static void main(String[] args) { try { CommPortIdentifier cpiCom1 = CommPortIdentifier.getPortIdentifier ("COM14"); OpenThread t1 = new OpenThread (" one ", cpiCom1); OpenThread t2 = new OpenThread (" two ", cpiCom1); OpenThread t3 = new OpenThread (" 003 ", cpiCom1); t1.start(); t2.start(); t3.start(); // comment this out and it runs with (expected) PortInUseException } catch (Exception e) { e.printStackTrace(); } } } class OpenThread extends Thread { String name; CommPortIdentifier cpi; CommPort cp; public OpenThread (String name, CommPortIdentifier cpi) { this.name = name; this.cpi = cpi; System.out.println (System.currentTimeMillis() + name + " thread created"); } public void run () { try { System.out.println (System.currentTimeMillis() + name + " opening"); cp = cpi.open(name, 2000); System.out.println (System.currentTimeMillis() + name + " opened - sleeping"); sleep (2000); // do the serial comms with the device. System.out.println (System.currentTimeMillis() + name + " slept - closing"); cp.close(); System.out.println (System.currentTimeMillis() + name + " closed - exiting"); } catch (Exception e) { System.out.println ("Error in thread: " + name ); e.printStackTrace(); } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070308/d9a163c5/attachment-0083.html From eu259473 at tele2.it Fri Mar 9 02:46:20 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 09 Mar 2007 10:46:20 +0100 Subject: [Rxtx] rxtx: tru64 unix make fails Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070309/3b654523/attachment-0083.html From lyon at docjava.com Fri Mar 9 03:58:32 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 Mar 2007 05:58:32 -0500 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi All, The deadlock issue is one that I have been thinking about for some time now. It seems to me that we need a resource manager that enables assignment to a known process. The one thing that seems important about serial ports is that two applications should not use the same serial port at the same time. When this happens, it throws an exception. OK. The exception is a response to a lock condition that arises from an unavailable resource. An abstract implementation (not born of native methods) might assign a serial port to an application, until the application releases it (or is forced to release it by some kill mechanism). Some resources (like a registry) can be reused. But others, like the serial port, cannot. In the case of the serial port, we would like, I think, to have the flyweight design pattern without sharing and with object assignment tracking. A means of breaking deadlock (like a leasing mechanism) seems very useful, to me. My guess is that we can serialize the state of the Parametric Singleton Pattern (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) into the Preferences of the System. Preferences.systemRoot() might help with that. When a resource is checked out, the lease time and owner are listed. A thread that does this can be killed, but applications outside of Java are problematic. There is a compelling problem here. It is not just serial ports. Sound cards, cameras, microphones, files, tape drives, etc. All are consumed resources that are assigned to an application (or user) and deprive other applications, or users, from use. What, if anything, should we do? At present we throw PortInUseExceptions. Is that it? Can we do better? OK, the port is in use. Now what? Do I have to be root to go remove lock files and kill applications? Is there a better way? Thanks! - Doug >I've just struck an issue using rxtx in a multi-threaded environment: > >If I have 3 threads trying to open *the same* >comm-port I get a deadlock in >CommPortIdentifier.open >If I have just 2, it works fine - I get a >PortInUseException which is nice and I can >handle it. > >The 3 thread->deadlock thing is causing me issues. >(Sample code below). > >This is from the java thread-dump > >Found one Java-level deadlock: >============================= >"Thread-2": > waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), > which is held by "Thread-1" >"Thread-1": > waiting to lock monitor 0x0003e9cc (object >0x2450e108, a gnu.io.CommPortIdentifier ), > which is held by "Thread-2" > >Java stack information for the threads listed above: >=================================================== >"Thread-2": > at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) > - waiting to lock <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) >"Thread-1": > at java.lang.Object.wait(Native Method) > - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) > - locked <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) > > >(Apart from this, rxtx is working fantastically for us). > >I'm thinking I'll have to implement some sort of >locking mechanism that *doesn't* use java >synchronization to prevent this situation. >(Which doesn't sound like a good idea to me). > >Any ideas? > >Thanks, > >Greg Hanna > >============= RXTXLockTest.java ======================================== > >import gnu.io.CommPort; >import gnu.io.CommPortIdentifier; > >/** > * @author Greg Hanna > * Minimal code to create a deadlock with rxtx in multithreaded open > */ >public class RXTXLockTest { > ? > ?public static void main(String[] args) { > ?try { > ?CommPortIdentifier cpiCom1 = >CommPortIdentifier.getPortIdentifier ("COM14"); > ?OpenThread t1 = new OpenThread (" one ", cpiCom1); > ?OpenThread t2 = new OpenThread (" two ", cpiCom1); > ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); > ?t1.start(); > ?t2.start(); > ?t3.start(); // comment this out >and it runs with (expected) PortInUseException > ?} catch (Exception e) { > ?e.printStackTrace(); > ?} > ?} >} > >class OpenThread extends Thread { > ?String name; > ?CommPortIdentifier cpi; > ?CommPort cp; > ?public OpenThread (String name, CommPortIdentifier cpi) { > ? this.name = name; > ?this.cpi = cpi; > ?System.out.println >(System.currentTimeMillis() + name + " thread >created"); > ?} > ?public void run () { > ?try { > ?System.out.println >(System.currentTimeMillis() + name + " opening"); > ?cp = cpi.open(name, 2000); > ?System.out.println >(System.currentTimeMillis() + name + " opened - >sleeping"); > ?sleep (2000); // do the serial comms with the device. > ?System.out.println >(System.currentTimeMillis() + name + " slept - >closing"); > ?cp.close(); > ?System.out.println >(System.currentTimeMillis() + name + " closed - >exiting"); > ?} catch (Exception e) { > System.out.println ("Error in thread: " + name ); > ?e.printStackTrace(); > ?} > ?} >} > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Mar 9 06:37:45 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 Mar 2007 06:37:45 -0700 (MST) Subject: [Rxtx] rxtx: tru64 unix make fails In-Reply-To: References: Message-ID: On Fri, 9 Mar 2007, "Giuseppe Marchese" wrote: > Sorry for delay. > ? > This is log for ./configure and make > error. > ? > thanks for attention > ? > Make: '%.java,$(TOP)/$(CLASSDEST)/%.class,$(wildcard $(SPATH)/*.java)': extra chars.? > Stop. > Hi Giuseppe You need to use GNU make with the Makefile. I suspect the tru64 make is not happy with those rules. > configure: exit 0 Looks like configure is fairly happy. From tjarvi at qbang.org Sat Mar 10 07:43:51 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 07:43:51 -0700 (MST) Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi Doug I have very little time to look into this further but what we could do is open up an rxtx 3 devel branch in which a proof of concept could be worked on. It could be the proof of concept for a JSR others including Sun could look at/work on or parts of it could be recycled in a JSR. I'm working very hard on rxtx right now but it does not show. I'm looking at win64, mac intel/ppc, usb bluetooth and usb serial dongles. Some are going to be more tested than others but they are all on the plate. I'll be pushing all the fixes upstream when they are done. So I'm very busy in 2.1 but we could open a new branch. On Fri, 9 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > The deadlock issue is one that I have been thinking about > for some time now. > It seems to me that we need a resource manager that enables assignment > to a known process. > > The one thing that seems important about serial > ports is that two applications should not use the > same serial port at the same time. When this > happens, it throws an exception. > OK. > > The exception is a response to a lock condition that > arises from an unavailable resource. > > An abstract implementation (not born of native methods) might > assign a serial port to an application, until the > application releases it (or is forced to release > it by some kill mechanism). > > Some resources (like a registry) can be reused. > But others, like the serial port, > cannot. > > In the case of the serial port, we would like, I think, to > have the flyweight design pattern > without sharing and with object assignment tracking. > A means of breaking deadlock (like a leasing > mechanism) seems very useful, to me. > > My guess is that we can serialize the state of the Parametric Singleton Pattern > (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) > into the Preferences of the System. Preferences.systemRoot() might help > with that. When a resource is checked out, the lease time and owner are > listed. A thread that does this can be killed, but applications outside of Java > are problematic. > > There is a compelling problem here. It is not just serial ports. > Sound cards, cameras, microphones, files, tape drives, etc. All are consumed > resources that are assigned to an application (or > user) and deprive other applications, > or users, from use. > > What, if anything, should we do? At present we throw PortInUseExceptions. > Is that it? > Can we do better? > OK, the port is in use. Now what? > Do I have to be root to go remove lock files and kill applications? > Is there a better way? > > Thanks! > - Doug > >> I've just struck an issue using rxtx in a multi-threaded environment: >> >> If I have 3 threads trying to open *the same* >> comm-port I get a deadlock in >> CommPortIdentifier.open >> If I have just 2, it works fine - I get a >> PortInUseException which is nice and I can >> handle it. >> >> The 3 thread->deadlock thing is causing me issues. >> (Sample code below). >> >> This is from the java thread-dump >> >> Found one Java-level deadlock: >> ============================= >> "Thread-2": >> waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), >> which is held by "Thread-1" >> "Thread-1": >> waiting to lock monitor 0x0003e9cc (object >> 0x2450e108, a gnu.io.CommPortIdentifier ), >> which is held by "Thread-2" >> >> Java stack information for the threads listed above: >> =================================================== >> "Thread-2": >> at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) >> - waiting to lock <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> "Thread-1": >> at java.lang.Object.wait(Native Method) >> - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) >> - locked <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> >> >> (Apart from this, rxtx is working fantastically for us). >> >> I'm thinking I'll have to implement some sort of >> locking mechanism that *doesn't* use java >> synchronization to prevent this situation. >> (Which doesn't sound like a good idea to me). >> >> Any ideas? >> >> Thanks, >> >> Greg Hanna >> >> ============= RXTXLockTest.java ======================================== >> >> import gnu.io.CommPort; >> import gnu.io.CommPortIdentifier; >> >> /** >> * @author Greg Hanna >> * Minimal code to create a deadlock with rxtx in multithreaded open >> */ >> public class RXTXLockTest { >> ? >> ?public static void main(String[] args) { >> ?try { >> ?CommPortIdentifier cpiCom1 = >> CommPortIdentifier.getPortIdentifier ("COM14"); >> ?OpenThread t1 = new OpenThread (" one ", cpiCom1); >> ?OpenThread t2 = new OpenThread (" two ", cpiCom1); >> ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); >> ?t1.start(); >> ?t2.start(); >> ?t3.start(); // comment this out >> and it runs with (expected) PortInUseException >> ?} catch (Exception e) { >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> class OpenThread extends Thread { >> ?String name; >> ?CommPortIdentifier cpi; >> ?CommPort cp; >> ?public OpenThread (String name, CommPortIdentifier cpi) { >> ? this.name = name; >> ?this.cpi = cpi; >> ?System.out.println >> (System.currentTimeMillis() + name + " thread >> created"); >> ?} >> ?public void run () { >> ?try { >> ?System.out.println >> (System.currentTimeMillis() + name + " opening"); >> ?cp = cpi.open(name, 2000); >> ?System.out.println >> (System.currentTimeMillis() + name + " opened - >> sleeping"); >> ?sleep (2000); // do the serial comms with the device. >> ?System.out.println >> (System.currentTimeMillis() + name + " slept - >> closing"); >> ?cp.close(); >> ?System.out.println >> (System.currentTimeMillis() + name + " closed - >> exiting"); >> ?} catch (Exception e) { >> System.out.println ("Error in thread: " + name ); >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 mm at UDel.Edu Sat Mar 10 14:48:32 2007 From: mm at UDel.Edu (Mike Markowski) Date: Sat, 10 Mar 2007 16:48:32 -0500 Subject: [Rxtx] rxtx and Sun's comm api Message-ID: <45F327B0.2060004@udel.edu> Hi all, I joined the list a few days ago and apologize for what is likely a frequently asked question, though I haven't yet found it anywhere. I learned about rxtx.org through the readme on Sun's version 2 of their comms api. They give recommendations in that readme regarding how a better comms api should be written. Is this the aim of rxtx.org? I wrote an app on my linux box using the Sun comms api (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the fact that only linux and Solaris are supported. So I'm glad to find rxtx.org and am just reading up on how make the conversion so Windows users will be able to run the program as well. At the same time I'm just curious if rxtx.org and Sun are both heading in the same direction. Thanks for any background or historical info. Feel free to point me to any www pages if my googling has just completely missed the target! Thanks again, Mike From tjarvi at qbang.org Sat Mar 10 15:35:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 15:35:25 -0700 (MST) Subject: [Rxtx] rxtx and Sun's comm api In-Reply-To: <45F327B0.2060004@udel.edu> References: <45F327B0.2060004@udel.edu> Message-ID: On Sat, 10 Mar 2007, Mike Markowski wrote: > Hi all, > > I joined the list a few days ago and apologize for what is likely a > frequently asked question, though I haven't yet found it anywhere. I > learned about rxtx.org through the readme on Sun's version 2 of their > comms api. They give recommendations in that readme regarding how a > better comms api should be written. Is this the aim of rxtx.org? > > I wrote an app on my linux box using the Sun comms api > (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the > fact that only linux and Solaris are supported. So I'm glad to find > rxtx.org and am just reading up on how make the conversion so Windows > users will be able to run the program as well. At the same time I'm > just curious if rxtx.org and Sun are both heading in the same direction. > > Thanks for any background or historical info. Feel free to point me to > any www pages if my googling has just completely missed the target! > I do not have any news (good or bad) concerning RXTX and Sun working together but perhaps others here do. The main goal of RXTX is to expose POSIX termios interfaces to java users. The future support of javax.comm is questionable. We do not have resources for everything. gnu.io (RXTX 2.1) will be supported going forward and functions the same as CommAPI 2.0. If you have control of the source code you are working with, I would not advise using CommAPI 2.0 javax.comm. We do support CommAPI 2.0 javax.comm for older applications but I do not think that will last much longer for practical reasons. The download interest in CommAPI 2.0 javax.comm support is becomming negligible on this end. There has been discussion of a JSR effort but I do not know of any status change since it was mentioned. One problem with a JSR is that even a light weight process is going to be difficult for RXTX at this time. Maybe that will change in the future but then again it may not. For now, we are just going forward 'as is' in rxtx 2.1 with package gnu.io while trying as a secondary effort to backport the changes to rxtx 2.0 for javax.comm support for users that do not have a choice. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Mar 11 07:19:40 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 11 Mar 2007 08:19:40 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: Hi All, I have been a proponent of a JSR that makes use of RXTX. I have executed the proper agreements with Sun. At this point we are in the: Early Draft Review of Draft Specifications Stage. The best thing to do is to enter the quiet period and create a specification. The question of exactly how we, as a group, want to approach this problem, remains open. Typically, we should have both a specification and a reference implementation. Thus, it would be to our best advantage to have a nice, stable, cross platform RXTX distro that adheres to the groups specification. Now, from a specification standpoint, my personal view on the matter is that we create a series of interfaces, with nice documentation (or at least javadoc). Is this a good idea? Should we have a pure interface specification for the communication API? There are several issues, in my mind, which still weigh on us. Hot-pluggable dongles, long discovery process on pop-up ports, lack of uniformity on device names, lack of uniformity on locking, a precise understanding of how the SerialPortResourceManager works (or even if we should have one). The more questions we answer in our reference implementation, the better our specification will get. RXTX is a good working prototype, but, I don't know if that is what we want to use for a specification. Here is what I have for a CommPortInterface: */ public interface CommPortInterface { /** * @return a string representation of this port. */ String toString(); /** * Gets the name of the communications port. This name should correspond to * something the user can identify, like the label on the hardware. * @return name of the port */ String getName(); /** * @return an input stream that can be used to read data from the * communications port. If the port doesn't support reading data, this * method returns null. *

* The blocking behaviour of this input stream depends on the threshold * and timeout values, as shown below for a read buffer size of n * bytes: * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ThresholdTimeoutBlocking behaviour
StateValueStateValue
disableddisabledblock until data is available
enabledm bytesdisabledblock until min(m, n) bytes are available
disabledenabledt msblock for t ms or until data is available
enabledm bytesenabledt msblock for t ms or until min(m, n) bytes are * available
* @throws java.io.IOException */ InputStream getInputStream() throws IOException; /** * @return an output stream that can be used to send data to the * communications port. If the port doesn't support sending data, this * method returns null. * @throws java.io.IOException */ OutputStream getOutputStream() throws IOException; /** * Closes this communications port. * All PortOwnershipListeners will be? * notified of this change of ownership. Further method calls on this? * object will throw IllegalStateException. Further calls on the? * associated InputStream or OutputStream will throw IOException. *

* Close does not block. Undelivered data is discarded. Blocked read and? * write operations are aborted if the underlying operating systems? * supports an IO abort mechanism. To await the delivery of undelivered? * data call OutputStream.flush() or OutputStream.close() before calling? * Port.close(). */ void close(); /** * Enables receive threshold. * When the specified threshold number of bytes are retrieved, read will * return immediately. * * @param thresh the number of bytes in the input buffer * @throws gnu.io.UnsupportedCommOperationException * if receive threshold is * not supported by the driver * @see #disableReceiveThreshold */ void enableReceiveThreshold(int thresh) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive threshold. * * @see #enableReceiveThreshold */ void disableReceiveThreshold(); /** * @return true if receive threshold is enabled. * * @see #enableReceiveThreshold */ boolean isReceiveThresholdEnabled(); /** * @return the receive threshold value. If receive threshold is diabled * or not supported, this value is meaningless. * * @see #enableReceiveThreshold */ int getReceiveThreshold(); /** * Enables receive timeout. * When the specified number of milliseconds have elapsed, read will * return immediately. * * @param rcvTimeout the number of milliseconds to block for * @throws gnu.io.UnsupportedCommOperationException * if receive timeout is * not supported by the driver * @see #disableReceiveTimeout */ void enableReceiveTimeout(int rcvTimeout) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive timeout. * * @see #enableReceiveTimeout */ void disableReceiveTimeout(); /** * @return true if receive timeout is enabled. * * @see #enableReceiveTimeout */ boolean isReceiveTimeoutEnabled(); /** * @return the receive timeout value. If receive timeout is diabled * or not supported, this value is meaningless. * * @see #enableReceiveTimeout */ int getReceiveTimeout(); /** * Enables receive framing. * The supplied byte value in the input suggests the end of the received * frame, and read returns immediately. Only the low 8 bits of the * supplied value are significant. * * @param framingByte the frame delimiter * @throws gnu.io.UnsupportedCommOperationException * if receive framing is * not supported by the driver * @see #disableReceiveFraming */ void enableReceiveFraming(int framingByte) throws UnsupportedCommOperationException; /** * Disables receive framing. * * @see #enableReceiveFraming */ void disableReceiveFraming(); /** * @return true if receive framing is enabled. * * @see #enableReceiveFraming */ boolean isReceiveFramingEnabled(); /** * @return true if receive framing byte. If receive framing is diabled * or not supported, this value is meaningless. * * @see #enableReceiveFraming */ int getReceiveFramingByte(); /** * Sets the input buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setInputBufferSize(int size); /** * @return the input buffer size. * The driver may choose not to report correct values. */ int getInputBufferSize(); /** * Sets the output buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setOutputBufferSize(int size); /** * @return the output buffer size. * The driver may choose not to report correct values. */ int getOutputBufferSize(); } What do you think of that? Note the wishy washy nature of the spec: The driver may choose to ignore this method. Is that good enough for us? Thanks! - Doug From ra85551 at gmail.com Sun Mar 11 08:44:45 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Sun, 11 Mar 2007 17:44:45 +0300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hello, world! I am writing application that communicates with modem via AT commands. My OS is Linux Kubuntu Feisty Herd, to ensure that my application will run properly under Windows XP I installed VMWare server. When I tried to send AT command and evaluate modem answer under WinXP @ VMWare server, I actually didn't receive anything. I think that VM settings are right, because I do can communicate with modem by using standard HyperTerminall as well as I can do on native Windows. So, why RXTX doesn't work under VM, but works under Linux and pure Windows XP (i tested it there) well? The send/receive method code follows. private String sendATCommand(String command, final String waitFor, final boolean isRegex, boolean isAddCRLF, long timeout) throws BeaconConnectException { final long POLL_PERIOD = 100; final int BUFFER_SIZE = 512; final byte[] buffer = new byte[BUFFER_SIZE]; final InputStream serialInput; final OutputStream serialOutput; try { serialInput = serialPort.getInputStream(); if (command != null) { serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } } catch (IOException e) { throw new MyException("serial I/O error"); } TimerTask task = new TimerTask() { int offset = 0; int bytesRead; public synchronized void run() { try { if (serialInput.available() > 0) { bytesRead = serialInput.read(buffer, offset, BUFFER_SIZE - offset); } else { return; } } catch (IOException e) { // do nothing - maybe next time we'll read something } offset += bytesRead; if (waitFor != null) { String temporary = new String(buffer, 0, offset).trim(); if (isRegex && temporary.matches(waitFor) || temporary.contains(waitFor)) { cancel(); notify(); } } } }; Timer timer = new Timer(); timer.schedule(task, POLL_PERIOD, POLL_PERIOD); synchronized (task) { try { task.wait(timeout); task.cancel(); } catch (InterruptedException e) { } } //Cut off leading and trailing CRs, LFs and zeroes String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); System.out.println(response); return response; } -- Pavel Parkhomenko From tjarvi at qbang.org Sun Mar 11 11:48:22 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:48:22 -0600 (MDT) Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: On Sun, 11 Mar 2007, Pavel Parkhomenko wrote: > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. > > private String sendATCommand(String command, final String waitFor, > final boolean isRegex, boolean isAddCRLF, long timeout) > throws BeaconConnectException > { > final long POLL_PERIOD = 100; > final int BUFFER_SIZE = 512; > final byte[] buffer = new byte[BUFFER_SIZE]; > final InputStream serialInput; > final OutputStream serialOutput; > try > { > serialInput = serialPort.getInputStream(); > if (command != null) > { > serialOutput = serialPort.getOutputStream(); > if (isAddCRLF) > { > command += "\r\n"; > } > System.out.println(command); > serialOutput.write(command.getBytes()); > } > } > catch (IOException e) > { > throw new MyException("serial I/O error"); > } > > TimerTask task = new TimerTask() > { > int offset = 0; > int bytesRead; > public synchronized void run() > { > try > { > if (serialInput.available() > 0) > { > bytesRead = serialInput.read(buffer, offset, > BUFFER_SIZE - offset); > } > else > { > return; > } > } > catch (IOException e) > { > // do nothing - maybe next time we'll read something > } > offset += bytesRead; > if (waitFor != null) > { > String temporary = new String(buffer, 0, offset).trim(); > if (isRegex && temporary.matches(waitFor) || > temporary.contains(waitFor)) > { > cancel(); > notify(); > } > } > } > }; > > Timer timer = new Timer(); > timer.schedule(task, POLL_PERIOD, POLL_PERIOD); > synchronized (task) { > try > { > task.wait(timeout); > task.cancel(); > } > catch (InterruptedException e) > { > } > } > //Cut off leading and trailing CRs, LFs and zeroes > String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); > System.out.println(response); > return response; > } > > > Hi Pavel VMWare should not be a problem. I've used it in the past - though not with a modem. Make sure nothing else is using the modem. Then look in the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an example that should work. Note that modems could care less what OS is on top. If you are trying to match new lines to the OS and sending it to the mode for AT commands, thats probably a mistake. Also it would not hurt to print out the individual bytes that you are sending to make sure they did not get mangled along the path. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 11:55:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:55:48 -0600 (MDT) Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: On Sun, 11 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > I have been a proponent of a JSR that makes > use of RXTX. I have executed the proper agreements with Sun. > > At this point we are in the: > Early Draft Review of Draft Specifications Stage. > > The best thing to do is to enter the quiet period and create > a specification. The question of exactly how we, as a group, > want to approach this problem, remains open. > > Typically, we should have both a specification and a reference > implementation. Thus, it would be to our best advantage to have > a nice, stable, cross platform RXTX distro that adheres to the > groups specification. > > Now, from a specification standpoint, my personal view on the matter is > that we create a series of interfaces, with nice documentation (or at least > javadoc). > > Is this a good idea? Should we have a pure interface specification for > the communication API? > > There are several issues, in my mind, which still weigh on us. > Hot-pluggable dongles, long discovery process on pop-up ports, > lack of uniformity on device names, lack of uniformity on locking, > a precise understanding of how the SerialPortResourceManager > works (or even if we should have one). > > The more questions we answer in our reference implementation, the > better our specification will get. RXTX is a good working prototype, > but, I don't know if that is what we want to use for a specification. > > Here is what I have for a CommPortInterface: > */ > public interface CommPortInterface { Hi Doug, I can start going through the method interfaces later this week and giving feedback. I would suggest that the JSR should not be too generic in nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel drivers that intend to look like EIA232 ports at the kernel driver level. some ideas: EIA232PortInterface TermiosInterface SerialPortInterface Something that differentiates this from thing like USB, I2C, ... which should not have to deal with legacy serial claiming to be the comm api. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 12:52:19 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 12:52:19 -0600 (MDT) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: No news is good news with these posts. I'll start the process of pinging legal a week from Monday on my end if nobody has objections to the proposal. I just want to make sure everyone has time to raise objections. Obviously, anyone can fork from a previous version if they don't like the new license. I suspect we can avoid that though. On Sun, 4 Mar 2007, Trent Jarvi wrote: > > For those that are wondering what is going on here, this > next bit is the meat of the changes. We agreed a long time > ago to put this disclaimer in. We did a so so job. It was > in rxtx 2.0, not well written, ... So some groups using > rxtx that would like to ship rxtx so users don't need to > download, install, go to the mail-list to find why it failed, > ... Then their legal teams tell them section 5 paragraph 2 > is a show stopper. > > That was never the intent. > > > Now going through what remains... > >> and might need a (TM) suffix to make Sun happy. > > Added disclaimer at the ended 'all trademarks belong...' > >> * Line #15ff - static vs. dynamic linking - you did >> not transcribe the text from the "controlled >> interface exception" when writing this text - and >> this was good so, because these terms originally >> refer to the GPL rather than the LGPL. I think though, >> that these 4 lines are the most important ones and >> should thus be really really clear. I hope that I >> meet your original intent with the following >> suggestions: >> 1.) Instead of "A program.." it would be better to >> say "An exectuable.." in order to be closer to >> the LGPL text. > > OK. As you can see I was trying to adjust GNU text there > for the LGPL. > >> 2.) It would be better to say .. "by being dynamically >> linked with it" to clearly indicate that dynamic >> linking is meant. The matter of compilation is >> already covered by the LGPL so mentioning it again >> just leads to confusion. > > used dynamically linked terminology. > >> 3.) It would be better to say .. "is considered a >> work that uses the library in contrast to section >> 5 of the LGPL, so the terms of the LGPL do not >> apply to the resulting executable". > > I tried to address this more upfront with an intent statement. > Let me know if you have problems with it. I also tried to > make it a little more clear what was derived from the GNU > solution by moving the link location closer to GNU's suggestion. > >> >> Note that LGPL section 5 says: ..."is called a >> "work that uses the Library". Such a work, in isolation, >> is not a derivative work of the Library, and therefore >> falls outside the scope of this License." >> The next paragraph of the LGPL is exactly the problematic >> one that I hope is clarified by the exception terms you >> give. >> > > Thats the intent. Here is the combined fixes. Note that only the > material in /*-- --*/ is being touched. The new GPL license is > there but unmodified. > > > ------------------------ begin proposed new license ------------------- > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Lesser General Public > | License as published by the Free Software Foundation; either > | version 2.1 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Lesser General Public License for more details. > | > | An executable that contains no derivative of any portion of RXTX, but > | is designed to work with RXTX by being dynamically linked with it, > | is considered a "work that uses the Library" subject to the terms and > | conditions of the GNU Lesser General Public License. > | > | The following has been added to the RXTX License to remove > | any confusion about linking to RXTX. We want to allow in part what > | section 5, paragraph 2 of the LGPL does not permit in the special > | case of linking over a controlled interface. The intent is to add a > | Java Specification Request or standards body defined interface in the > | future as another exception but one is not currently available. > | > | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface > | > | As a special exception, the copyright holders of RXTX give you > | permission to link RXTX with independent modules that communicate with > | RXTX solely through the Sun Microsytems CommAPI interface version 2, > | regardless of the license terms of these independent modules, and to copy > | and distribute the resulting combined work under terms of your choice, > | provided that every copy of the combined work is accompanied by a complete > | copy of the source code of RXTX (the version of RXTX used to produce the > | combined work), being distributed under the terms of the GNU Lesser General > | Public License plus this exception. An independent module is a > | module which is not derived from or based on RXTX. > | > | Note that people who make modified versions of RXTX are not obligated > | to grant this special exception for their modified versions; it is > | their choice whether to do so. The GNU Lesser General Public License > | gives permission to release a modified version without this exception; this > | exception also makes it possible to release a modified version which > | carries forward this exception. > | > | You should have received a copy of the GNU Lesser General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > | All trademarks belong to their respective owners. > --------------------------------------------------------------------------*/ > > The original GNU Lesser General Public License Follows. > > > GNU LESSER GENERAL PUBLIC LICENSE > Version 2.1, February 1999 > > Copyright (C) 1991, 1999 Free Software Foundation, Inc. > 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > Everyone is permitted to copy and distribute verbatim copies > of this license document, but changing it is not allowed. > > [This is the first released version of the Lesser GPL. It also counts > as the successor of the GNU Library Public License, version 2, hence > the version number 2.1.] > > Preamble > > The licenses for most software are designed to take away your > freedom to share and change it. By contrast, the GNU General Public > Licenses are intended to guarantee your freedom to share and change > free software--to make sure the software is free for all its users. > > This license, the Lesser General Public License, applies to some > specially designated software packages--typically libraries--of the > Free Software Foundation and other authors who decide to use it. You > can use it too, but we suggest you first think carefully about whether > this license or the ordinary General Public License is the better > strategy to use in any particular case, based on the explanations below. > > When we speak of free software, we are referring to freedom of use, > not price. Our General Public Licenses are designed to make sure that > you have the freedom to distribute copies of free software (and charge > for this service if you wish); that you receive source code or can get > it if you want it; that you can change the software and use pieces of > it in new free programs; and that you are informed that you can do > these things. > > To protect your rights, we need to make restrictions that forbid > distributors to deny you these rights or to ask you to surrender these > rights. These restrictions translate to certain responsibilities for > you if you distribute copies of the library or if you modify it. > > For example, if you distribute copies of the library, whether gratis > or for a fee, you must give the recipients all the rights that we gave > you. You must make sure that they, too, receive or can get the source > code. If you link other code with the library, you must provide > complete object files to the recipients, so that they can relink them > with the library after making changes to the library and recompiling > it. And you must show them these terms so they know their rights. > > We protect your rights with a two-step method: (1) we copyright the > library, and (2) we offer you this license, which gives you legal > permission to copy, distribute and/or modify the library. > > To protect each distributor, we want to make it very clear that > there is no warranty for the free library. Also, if the library is > modified by someone else and passed on, the recipients should know > that what they have is not the original version, so that the original > author's reputation will not be affected by problems that might be > introduced by others. > > Finally, software patents pose a constant threat to the existence of > any free program. We wish to make sure that a company cannot > effectively restrict the users of a free program by obtaining a > restrictive license from a patent holder. Therefore, we insist that > any patent license obtained for a version of the library must be > consistent with the full freedom of use specified in this license. > > Most GNU software, including some libraries, is covered by the > ordinary GNU General Public License. This license, the GNU Lesser > General Public License, applies to certain designated libraries, and > is quite different from the ordinary General Public License. We use > this license for certain libraries in order to permit linking those > libraries into non-free programs. > > When a program is linked with a library, whether statically or using > a shared library, the combination of the two is legally speaking a > combined work, a derivative of the original library. The ordinary > General Public License therefore permits such linking only if the > entire combination fits its criteria of freedom. The Lesser General > Public License permits more lax criteria for linking other code with > the library. > > We call this license the "Lesser" General Public License because it > does Less to protect the user's freedom than the ordinary General > Public License. It also provides other free software developers Less > of an advantage over competing non-free programs. These disadvantages > are the reason we use the ordinary General Public License for many > libraries. However, the Lesser license provides advantages in certain > special circumstances. > > For example, on rare occasions, there may be a special need to > encourage the widest possible use of a certain library, so that it becomes > a de-facto standard. To achieve this, non-free programs must be > allowed to use the library. A more frequent case is that a free > library does the same job as widely used non-free libraries. In this > case, there is little to gain by limiting the free library to free > software only, so we use the Lesser General Public License. > > In other cases, permission to use a particular library in non-free > programs enables a greater number of people to use a large body of > free software. For example, permission to use the GNU C Library in > non-free programs enables many more people to use the whole GNU > operating system, as well as its variant, the GNU/Linux operating > system. > > Although the Lesser General Public License is Less protective of the > users' freedom, it does ensure that the user of a program that is > linked with the Library has the freedom and the wherewithal to run > that program using a modified version of the Library. > > The precise terms and conditions for copying, distribution and > modification follow. Pay close attention to the difference between a > "work based on the library" and a "work that uses the library". The > former contains code derived from the library, whereas the latter must > be combined with the library in order to run. > > GNU LESSER GENERAL PUBLIC LICENSE > TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION > > 0. This License Agreement applies to any software library or other > program which contains a notice placed by the copyright holder or > other authorized party saying it may be distributed under the terms of > this Lesser General Public License (also called "this License"). > Each licensee is addressed as "you". > > A "library" means a collection of software functions and/or data > prepared so as to be conveniently linked with application programs > (which use some of those functions and data) to form executables. > > The "Library", below, refers to any such software library or work > which has been distributed under these terms. A "work based on the > Library" means either the Library or any derivative work under > copyright law: that is to say, a work containing the Library or a > portion of it, either verbatim or with modifications and/or translated > straightforwardly into another language. (Hereinafter, translation is > included without limitation in the term "modification".) > > "Source code" for a work means the preferred form of the work for > making modifications to it. For a library, complete source code means > all the source code for all modules it contains, plus any associated > interface definition files, plus the scripts used to control compilation > and installation of the library. > > Activities other than copying, distribution and modification are not > covered by this License; they are outside its scope. The act of > running a program using the Library is not restricted, and output from > such a program is covered only if its contents constitute a work based > on the Library (independent of the use of the Library in a tool for > writing it). Whether that is true depends on what the Library does > and what the program that uses the Library does. > > 1. You may copy and distribute verbatim copies of the Library's > complete source code as you receive it, in any medium, provided that > you conspicuously and appropriately publish on each copy an > appropriate copyright notice and disclaimer of warranty; keep intact > all the notices that refer to this License and to the absence of any > warranty; and distribute a copy of this License along with the > Library. > > You may charge a fee for the physical act of transferring a copy, > and you may at your option offer warranty protection in exchange for a > fee. > > 2. You may modify your copy or copies of the Library or any portion > of it, thus forming a work based on the Library, and copy and > distribute such modifications or work under the terms of Section 1 > above, provided that you also meet all of these conditions: > > a) The modified work must itself be a software library. > > b) You must cause the files modified to carry prominent notices > stating that you changed the files and the date of any change. > > c) You must cause the whole of the work to be licensed at no > charge to all third parties under the terms of this License. > > d) If a facility in the modified Library refers to a function or a > table of data to be supplied by an application program that uses > the facility, other than as an argument passed when the facility > is invoked, then you must make a good faith effort to ensure that, > in the event an application does not supply such function or > table, the facility still operates, and performs whatever part of > its purpose remains meaningful. > > (For example, a function in a library to compute square roots has > a purpose that is entirely well-defined independent of the > application. Therefore, Subsection 2d requires that any > application-supplied function or table used by this function must > be optional: if the application does not supply it, the square > root function must still compute square roots.) > > These requirements apply to the modified work as a whole. If > identifiable sections of that work are not derived from the Library, > and can be reasonably considered independent and separate works in > themselves, then this License, and its terms, do not apply to those > sections when you distribute them as separate works. But when you > distribute the same sections as part of a whole which is a work based > on the Library, the distribution of the whole must be on the terms of > this License, whose permissions for other licensees extend to the > entire whole, and thus to each and every part regardless of who wrote > it. > > Thus, it is not the intent of this section to claim rights or contest > your rights to work written entirely by you; rather, the intent is to > exercise the right to control the distribution of derivative or > collective works based on the Library. > > In addition, mere aggregation of another work not based on the Library > with the Library (or with a work based on the Library) on a volume of > a storage or distribution medium does not bring the other work under > the scope of this License. > > 3. You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. To do > this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version 2, > instead of to this License. (If a newer version than version 2 of the > ordinary GNU General Public License has appeared, then you can specify > that version instead if you wish.) Do not make any other change in > these notices. > > Once this change is made in a given copy, it is irreversible for > that copy, so the ordinary GNU General Public License applies to all > subsequent copies and derivative works made from that copy. > > This option is useful when you wish to copy part of the code of > the Library into a program that is not a library. > > 4. You may copy and distribute the Library (or a portion or > derivative of it, under Section 2) in object code or executable form > under the terms of Sections 1 and 2 above provided that you accompany > it with the complete corresponding machine-readable source code, which > must be distributed under the terms of Sections 1 and 2 above on a > medium customarily used for software interchange. > > If distribution of object code is made by offering access to copy > from a designated place, then offering equivalent access to copy the > source code from the same place satisfies the requirement to > distribute the source code, even though third parties are not > compelled to copy the source along with the object code. > > 5. A program that contains no derivative of any portion of the > Library, but is designed to work with the Library by being compiled or > linked with it, is called a "work that uses the Library". Such a > work, in isolation, is not a derivative work of the Library, and > therefore falls outside the scope of this License. > > However, linking a "work that uses the Library" with the Library > creates an executable that is a derivative of the Library (because it > contains portions of the Library), rather than a "work that uses the > library". The executable is therefore covered by this License. > Section 6 states terms for distribution of such executables. > > When a "work that uses the Library" uses material from a header file > that is part of the Library, the object code for the work may be a > derivative work of the Library even though the source code is not. > Whether this is true is especially significant if the work can be > linked without the Library, or if the work is itself a library. The > threshold for this to be true is not precisely defined by law. > > If such an object file uses only numerical parameters, data > structure layouts and accessors, and small macros and small inline > functions (ten lines or less in length), then the use of the object > file is unrestricted, regardless of whether it is legally a derivative > work. (Executables containing this object code plus portions of the > Library will still fall under Section 6.) > > Otherwise, if the work is a derivative of the Library, you may > distribute the object code for the work under the terms of Section 6. > Any executables containing that work also fall under Section 6, > whether or not they are linked directly with the Library itself. > > 6. As an exception to the Sections above, you may also combine or > link a "work that uses the Library" with the Library to produce a > work containing portions of the Library, and distribute that work > under terms of your choice, provided that the terms permit > modification of the work for the customer's own use and reverse > engineering for debugging such modifications. > > You must give prominent notice with each copy of the work that the > Library is used in it and that the Library and its use are covered by > this License. You must supply a copy of this License. If the work > during execution displays copyright notices, you must include the > copyright notice for the Library among them, as well as a reference > directing the user to the copy of this License. Also, you must do one > of these things: > > a) Accompany the work with the complete corresponding > machine-readable source code for the Library including whatever > changes were used in the work (which must be distributed under > Sections 1 and 2 above); and, if the work is an executable linked > with the Library, with the complete machine-readable "work that > uses the Library", as object code and/or source code, so that the > user can modify the Library and then relink to produce a modified > executable containing the modified Library. (It is understood > that the user who changes the contents of definitions files in the > Library will not necessarily be able to recompile the application > to use the modified definitions.) > > b) Use a suitable shared library mechanism for linking with the > Library. A suitable mechanism is one that (1) uses at run time a > copy of the library already present on the user's computer system, > rather than copying library functions into the executable, and (2) > will operate properly with a modified version of the library, if > the user installs one, as long as the modified version is > interface-compatible with the version that the work was made with. > > c) Accompany the work with a written offer, valid for at > least three years, to give the same user the materials > specified in Subsection 6a, above, for a charge no more > than the cost of performing this distribution. > > d) If distribution of the work is made by offering access to copy > from a designated place, offer equivalent access to copy the above > specified materials from the same place. > > e) Verify that the user has already received a copy of these > materials or that you have already sent this user a copy. > > For an executable, the required form of the "work that uses the > Library" must include any data and utility programs needed for > reproducing the executable from it. However, as a special exception, > the materials to be distributed need not include anything that is > normally distributed (in either source or binary form) with the major > components (compiler, kernel, and so on) of the operating system on > which the executable runs, unless that component itself accompanies > the executable. > > It may happen that this requirement contradicts the license > restrictions of other proprietary libraries that do not normally > accompany the operating system. Such a contradiction means you cannot > use both them and the Library together in an executable that you > distribute. > > 7. You may place library facilities that are a work based on the > Library side-by-side in a single library together with other library > facilities not covered by this License, and distribute such a combined > library, provided that the separate distribution of the work based on > the Library and of the other library facilities is otherwise > permitted, and provided that you do these two things: > > a) Accompany the combined library with a copy of the same work > based on the Library, uncombined with any other library > facilities. This must be distributed under the terms of the > Sections above. > > b) Give prominent notice with the combined library of the fact > that part of it is a work based on the Library, and explaining > where to find the accompanying uncombined form of the same work. > > 8. You may not copy, modify, sublicense, link with, or distribute > the Library except as expressly provided under this License. Any > attempt otherwise to copy, modify, sublicense, link with, or > distribute the Library is void, and will automatically terminate your > rights under this License. However, parties who have received copies, > or rights, from you under this License will not have their licenses > terminated so long as such parties remain in full compliance. > > 9. You are not required to accept this License, since you have not > signed it. However, nothing else grants you permission to modify or > distribute the Library or its derivative works. These actions are > prohibited by law if you do not accept this License. Therefore, by > modifying or distributing the Library (or any work based on the > Library), you indicate your acceptance of this License to do so, and > all its terms and conditions for copying, distributing or modifying > the Library or works based on it. > > 10. Each time you redistribute the Library (or any work based on the > Library), the recipient automatically receives a license from the > original licensor to copy, distribute, link with or modify the Library > subject to these terms and conditions. You may not impose any further > restrictions on the recipients' exercise of the rights granted herein. > You are not responsible for enforcing compliance by third parties with > this License. > > 11. If, as a consequence of a court judgment or allegation of patent > infringement or for any other reason (not limited to patent issues), > conditions are imposed on you (whether by court order, agreement or > otherwise) that contradict the conditions of this License, they do not > excuse you from the conditions of this License. If you cannot > distribute so as to satisfy simultaneously your obligations under this > License and any other pertinent obligations, then as a consequence you > may not distribute the Library at all. For example, if a patent > license would not permit royalty-free redistribution of the Library by > all those who receive copies directly or indirectly through you, then > the only way you could satisfy both it and this License would be to > refrain entirely from distribution of the Library. > > If any portion of this section is held invalid or unenforceable under any > particular circumstance, the balance of the section is intended to apply, > and the section as a whole is intended to apply in other circumstances. > > It is not the purpose of this section to induce you to infringe any > patents or other property right claims or to contest validity of any > such claims; this section has the sole purpose of protecting the > integrity of the free software distribution system which is > implemented by public license practices. Many people have made > generous contributions to the wide range of software distributed > through that system in reliance on consistent application of that > system; it is up to the author/donor to decide if he or she is willing > to distribute software through any other system and a licensee cannot > impose that choice. > > This section is intended to make thoroughly clear what is believed to > be a consequence of the rest of this License. > > 12. If the distribution and/or use of the Library is restricted in > certain countries either by patents or by copyrighted interfaces, the > original copyright holder who places the Library under this License may add > an explicit geographical distribution limitation excluding those countries, > so that distribution is permitted only in or among countries not thus > excluded. In such case, this License incorporates the limitation as if > written in the body of this License. > > 13. The Free Software Foundation may publish revised and/or new > versions of the Lesser General Public License from time to time. > Such new versions will be similar in spirit to the present version, > but may differ in detail to address new problems or concerns. > > Each version is given a distinguishing version number. If the Library > specifies a version number of this License which applies to it and > "any later version", you have the option of following the terms and > conditions either of that version or of any later version published by > the Free Software Foundation. If the Library does not specify a > license version number, you may choose any version ever published by > the Free Software Foundation. > > 14. If you wish to incorporate parts of the Library into other free > programs whose distribution conditions are incompatible with these, > write to the author to ask for permission. For software which is > copyrighted by the Free Software Foundation, write to the Free > Software Foundation; we sometimes make exceptions for this. Our > decision will be guided by the two goals of preserving the free status > of all derivatives of our free software and of promoting the sharing > and reuse of software generally. > > NO WARRANTY > > 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO > WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. > EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR > OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY > KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE > IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE > LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME > THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. > > 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN > WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY > AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU > FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR > CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE > LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING > RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A > FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF > SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH > DAMAGES. > > END OF TERMS AND CONDITIONS > > How to Apply These Terms to Your New Libraries > > If you develop a new library, and you want it to be of the greatest > possible use to the public, we recommend making it free software that > everyone can redistribute and change. You can do so by permitting > redistribution under these terms (or, alternatively, under the terms of the > ordinary General Public License). > > To apply these terms, attach the following notices to the library. It is > safest to attach them to the start of each source file to most effectively > convey the exclusion of warranty; and each file should have at least the > "copyright" line and a pointer to where the full notice is found. > > > Copyright (C) > > This library is free software; you can redistribute it and/or > modify it under the terms of the GNU Lesser General Public > License as published by the Free Software Foundation; either > version 2.1 of the License, or (at your option) any later version. > > This library is distributed in the hope that it will be useful, > but WITHOUT ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > Lesser General Public License for more details. > > You should have received a copy of the GNU Lesser General Public > License along with this library; if not, write to the Free Software > Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > > Also add information on how to contact you by electronic and paper mail. > > You should also get your employer (if you work as a programmer) or your > school, if any, to sign a "copyright disclaimer" for the library, if > necessary. Here is a sample; alter the names: > > Yoyodyne, Inc., hereby disclaims all copyright interest in the > library `Frob' (a library for tweaking knobs) written by James Random Hacker. > > , 1 April 1990 > Ty Coon, President of Vice > > That's all there is to it! > ------------------------ end of proposed license ------------------ > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From gjhanna at gmail.com Sun Mar 11 14:21:17 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Mon, 12 Mar 2007 09:21:17 +1300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hi Pavel, We are using RXTX under VMWare server in production, quite satisfactorily. We're using Red Hat Enterprise Server 4, and ... Whatever the "enterprise" VMWare product is. Regards, Greg H > Subject: [Rxtx] RXTX under VMWare server > To: rxtx at qbang.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. [ ... snip ... ] -- Pavel Parkhomenko -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070311/4cebb6f9/attachment-0080.html From gergg at cox.net Sun Mar 11 23:39:19 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 12 Mar 2007 00:39:19 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: <45F4E787.6050502@cox.net> Trent Jarvi wrote: > I can start going through the method interfaces later this week and giving > feedback. I would suggest that the JSR should not be too generic in > nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel > drivers that intend to look like EIA232 ports at the kernel driver level. > > some ideas: > > EIA232PortInterface > TermiosInterface > SerialPortInterface > > Something that differentiates this from thing like USB, I2C, ... which > should not have to deal with legacy serial claiming to be the comm api. I'm going to throw out a suggestion, which I am mostly serious about. What would happen if we took the appropriate bits of the J2ME connector API, and just used that as the new COMM API so that finally JSE and JME had a common foundation for these kinds of things? Gregg Wonderly From ra85551 at gmail.com Mon Mar 12 09:08:37 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Mon, 12 Mar 2007 18:08:37 +0300 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Should any application use the modem, HyperTerminal won't be able to talk to the modem. But it actually can send and receive AT comands, while my application cannot :-( > Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Thansk for the reference. I examined that example and found that there's no significant differences between my read/write implementation and that one, except that SimpleSnuV1 listens for serialEvent's, but not for sake of data retrieval, just for printing them out - I don't know why ;-) > Note that modems could care less what OS is on top. If you are trying to > match new lines to the OS and sending it to the mode for AT commands, > thats probably a mistake. I do send strings to serial port, not to OS, and do try to get answers back. If it is the mistake, what's the right way? > Also it would not hurt to print out the > individual bytes that you are sending to make sure they did not get > mangled along the path. Yeah, I am printing these bytes before doing write, but it means that I only see what I intend to write. How can I ensure that these bytes have gone out of the box and reached my modem? BTW, I found that my send/receive method is complex enough, so I've rewritten it. Please, see the following code and point any mistakes, because I don't know where can they remain yet. private static final int LARGE_TIMEOUT = 15000; private static final int SMALL_TIMEOUT = 500; ... private String sendATCommand(String command, String waitFor, boolean isRegex, boolean isAddCRLF) throws BeaconConnectException { byte[] buffer = new byte[512]; int offset; String result = ""; try { if (waitFor != null) { serialPort.enableReceiveTimeout(LARGE_TIMEOUT); } else { serialPort.enableReceiveTimeout(SMALL_TIMEOUT); } if (command != null) { OutputStream serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } offset = 0; InputStream serialInput = serialPort.getInputStream(); while (serialInput.available() != -1) { int bytesRead = serialInput.read(buffer, offset, buffer.length - offset); if (bytesRead == 0) { break; } offset += bytesRead; result = new String(buffer, 0, offset).trim(); if (waitFor != null) { System.out.println(result); if (isRegex && result.matches(waitFor) || result.contains(waitFor)) { break; } } } } catch (UnsupportedCommOperationException e) { throw new MyException("unsupported operation"); } catch (IOException e) { throw new MytException("serial I/O error"); } return result; } -- Pavel Parkhomenko From clayno at hotpop.com Thu Mar 15 02:47:34 2007 From: clayno at hotpop.com (Christopher Layno) Date: Thu, 15 Mar 2007 16:47:34 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi, we're using the latest release of rxtx (2.1-7r2) for our system that has two applications using the library. one application sends requests to the modem while the other simply checks the modem status. we deployed our system on a pentium machine with red hat linux 9.0 installed. now the problem arises when these two applications try to access the same modem at the same time. one of them will eventually have to throw the PortInUseException as shown below: 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException gnu.io.PortInUseException: root PID = 743 Program = java root PID = 743 Program = java root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) this was expected. what we didn't expect though was that if we repeat the scenario 5 times, always 5 times, the application would also throw a VM error: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4473CD21 Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so Current Java thread: at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) - locked <0x44cfd4c8> (a gnu.io.CommPortIdentifier) at ************ at ************ - locked <0x4476a468> (a **********) at ************ at ************ at ************ at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java :261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages( TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run( TCPTransport.java:701) at java.lang.Thread.run(Thread.java:534) note: i replaced some sensitive data with asterisks our team has looked everywhere on the internet, including your mail archives, for a solution to this problem but to no avail. i really hope you could help us out on this one. thanks in advance! best regards, chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070315/1936460a/attachment-0077.html From tjarvi at qbang.org Fri Mar 16 04:30:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 04:30:25 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: On Thu, 15 Mar 2007, Christopher Layno wrote: > hi, > > we're using the latest release of rxtx (2.1-7r2) for our system that has two > applications using the library. one application sends requests to the modem > while the other simply checks the modem status. we deployed our system on a > pentium machine with red hat linux 9.0 installed. > > now the problem arises when these two applications try to access the same > modem at the same time. one of them will eventually have to throw the > PortInUseException as shown below: > > 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException > gnu.io.PortInUseException: root PID = 743 Program = java root PID = > 743 Program = java root PID = 743 Program = ??? root PID = 743 Program > = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root > PID = 743 Program = ??? root PID = 743 Program = ??? > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > > this was expected. what we didn't expect though was that if we repeat the > scenario 5 times, always 5 times, the application would also throw a VM > error: > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x4473CD21 > Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 > Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so > > Current Java thread: > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) Hi Chris The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. The code is originally by Werner Almesberger. He gave us permission to use it in rxtx. You might look at what has changed since 1998 in his fuser application. Or you can just do like other OSs and do the following in fuserImp.c JNIEXPORT jstring JNICALL Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv *env, jobject obj, jstring arg) { return (*env)->NewStringUTF(env, "Unknown Application"); } It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. -- Trent Jarvi tjarvi at qang.org From Adrien.TOS at ingenico.com Fri Mar 16 05:11:12 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Fri, 16 Mar 2007 12:11:12 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903CBC312@frsnprexc1.usr.ingenico.loc> Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070316/972ab214/attachment-0076.html From joachim at buechse.de Fri Mar 16 05:13:24 2007 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 16 Mar 2007 12:13:24 +0100 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. From tjarvi at qbang.org Fri Mar 16 16:36:29 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 16:36:29 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Fri Mar 16 16:02:23 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 16 Mar 2007 18:02:23 -0400 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Not all platforms are Unix based. Also mixing native library usage and command-line calls is not an elegant solution, IMHO. One or the other, but not both. Andre On 16-Mar-07, at 07:13 , Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is > trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We >> only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From clayno at hotpop.com Sun Mar 18 22:17:28 2007 From: clayno at hotpop.com (Christopher Layno) Date: Mon, 19 Mar 2007 12:17:28 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi everyone, thank you so much for your replies. they were really helpful. anyway, before i sent the email, my team was already implementing a temporary solution by using joachim's suggestion. we invoked a lsof command from our java code although i share the same concern with trent and andre-john about portability issues. that's why i said it's just temporary. my superiors have yet to approve our bug fix. so my question now is this: is recompiling the rxtx source code the only way to solve this problem? because if it's the only solution, then i think my superiors would rather have a new release from the rxtx community itself that fixes this bug(?) rather than have my team recompile the source code. best regards, chris Trent Jarvi wrote: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. ... It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070318/237463b2/attachment-0073.html From tjarvi at qbang.org Mon Mar 19 16:20:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Mar 2007 16:20:52 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: Hi Chris I can compile a new version after the 21st if you do not feel comfortable doing so. Please send me an email reminder off-line then. On Mon, 19 Mar 2007, Christopher Layno wrote: > hi everyone, > > thank you so much for your replies. they were really helpful. > > anyway, before i sent the email, my team was already implementing a > temporary solution by using joachim's suggestion. > we invoked a lsof command from our java code although i share the same > concern with trent and andre-john about > portability issues. that's why i said it's just temporary. my superiors have > yet to approve our bug fix. > > so my question now is this: is recompiling the rxtx source code the only way > to solve this problem? because if it's the only > solution, then i think my superiors would rather have a new release from the > rxtx community itself that fixes this bug(?) > rather than have my team recompile the source code. > > best regards, > > chris > > Trent Jarvi wrote: > > Hi Joachim > > It would be nice to have that functionality but calling the program > introduces too many issues imho. Explaining to someone why rxtx invoked a > rogue lsof does not sound very interesting. > > On Fri, 16 Mar 2007, Joachim Buechse wrote: > > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: > > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. > > _______________________________________________ > Rxtx mailing list > Rxtx 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 Eric.Arseneau at sun.com Tue Mar 20 11:47:33 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Tue, 20 Mar 2007 10:47:33 -0700 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 Message-ID: <46001E35.9040608@sun.com> Anyone have any experience with RXTX working with JDK 6 on other platforms ? From mm at UDel.Edu Tue Mar 20 12:18:29 2007 From: mm at UDel.Edu (Mike Markowski) Date: Tue, 20 Mar 2007 14:18:29 -0400 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 In-Reply-To: <46001E35.9040608@sun.com> References: <46001E35.9040608@sun.com> Message-ID: <46002575.4000306@udel.edu> Eric Arseneau wrote: > Anyone have any experience with RXTX working with JDK 6 on other platforms ? I'm using 32 bit intel, gentoo linux, jdk6 with no problems. My applications only use a serial port, though, nothing on the parallel port. Mike From falko.guderian at gmx.de Wed Mar 21 08:17:35 2007 From: falko.guderian at gmx.de (Falko Guderian) Date: Wed, 21 Mar 2007 15:17:35 +0100 Subject: [Rxtx] RXTX binaries for SH4 Message-ID: <46013E7F.40102@gmx.de> Dear developers, I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no possiblities to compile the source code. Better, I'm not able to do this at the moment. Can you provide me with rxtxSerial.dll (SH4) in the rxtx-2.1-8-testing version? (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) The reason for the testing version is I need custom baud rates. Thanks for help. Kind regards, Falko Guderian From tjarvi at qbang.org Wed Mar 21 21:38:37 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Mar 2007 21:38:37 -0600 (MDT) Subject: [Rxtx] RXTX binaries for SH4 In-Reply-To: <46013E7F.40102@gmx.de> References: <46013E7F.40102@gmx.de> Message-ID: On Wed, 21 Mar 2007, Falko Guderian wrote: > Dear developers, > > I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no > possiblities to compile the source code. Better, I'm not able to do this > at the moment. Can you provide me with rxtxSerial.dll (SH4) in the > rxtx-2.1-8-testing version? > (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) > > The reason for the testing version is I need custom baud rates. > > Thanks for help. > Hi Falko WinCE binary format is not supported by gcc. That makes compiling limited to those familiar with the WinCE tools. I hope someone is able to provide them for you but it is not likely. WinCE has been compiled by others in the past but rxtx.org builds have never included WinCE. There is some information with the source concerning WinCE builds if you decide to do it. We can share your results too if you like. The source in the WinCE has never been updated for the custom baud rate. That would need changes from the main source I presume. If you look at the source, you will note that Michal Hobot created a mini fork in the source to handle wince but it has not been updated for 3 years. -- Trent Jarvi tjarvi at qbang.org From Adrien.TOS at ingenico.com Thu Mar 22 07:08:55 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Thu, 22 Mar 2007 14:08:55 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Hi everybody, Do you have any comments on this issue? Thanks! AT ________________________________ De : Adrien TOS Envoy? : vendredi 16 mars 2007 12:11 ? : 'rxtx at qbang.org' Cc : Adrien TOS Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070322/2306c538/attachment-0069.html From jeremy.reeve at zen.co.uk Mon Mar 19 07:36:04 2007 From: jeremy.reeve at zen.co.uk (Jeremy S. Reeve) Date: Mon, 19 Mar 2007 13:36:04 +0000 Subject: [Rxtx] rxtx failing to compile on Fedora Core 6 Message-ID: <1174311364.21865.6.camel@d9thc> When trying to compile latest source : rxtx-2.1-7r2 I get the following when running configure: ---------------- checking os.version 2.6.18-1.2200.fc5smp WARNING: configure is having a hard time determining which directory contains the file jni_md.h. Edit Makefile and fix the variable JAVANATINC to point to the correct directory. The following options are available: /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/ /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/linux/ If there are more than one option available the first was selected. WARNING: Kernel include files do not match the current kernel configure: creating ./config.status ------------------------ which seems OK checking the resultant Makefile but when attempting to build with gmake install I get the following output : ---------------------- 34 problems (34 warnings)/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/javah -classpath .:/home/jsr/rxtxsrc/rxtx-2.1-7r2:/home/jsr/rxtxsrc/rxtx-2.1-7r2/src:/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/ext/RXTXcomm.jar -d i686-pc-linux-gnu -jni `(for i in CommDriver CommPortEnumerator CommPortIdentifier CommPort CommPortOwnershipListener Configure I2C I2CPortEvent I2CPortEventListener I2CPort LPRPort NoSuchPortException ParallelPortEvent ParallelPortEventListener ParallelPort PortInUseException Raw RawPortEvent RawPortEventListener RawPort RS485 RS485PortEvent RS485PortEventListener RS485Port RXTXCommDriver RXTXPort RXTXVersion SerialPortEvent SerialPortEventListener SerialPort UnsupportedCommOperationException UnSupportedLoggerException Zystem;do \ if grep > /dev/null native.* \( /home/jsr/rxtxsrc/rxtx-2.1-7r2/./src/$i.java; then \ echo gnu.io.$i; \ fi; \ done)` i686-pc-linux-gnu/gnu_io_CommPortIdentifier.h: No such file or directory make: *** [/home/jsr/rxtxsrc/rxtx-2.1-7r2/gnu/io/CommDriver.class] Error 1 ------------------------ Any ideas or pointers? Regards, Jeremy From tjarvi at qbang.org Sat Mar 24 08:12:54 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 Mar 2007 08:12:54 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > From Adrien.TOS at ingenico.com Sat Mar 24 11:53:22 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Sat, 24 Mar 2007 18:53:22 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> I do not have the threshold setting enabled, I have explicitely disabled it with: port_.disableReceiveThreshold(); I have also run the same tests with the threshold setting enabled, but they also fail in the same way as described below. So it seems there is a problem with timeout handling on Win32? ________________________________ From: rxtx-bounces at qbang.org on behalf of Trent Jarvi Sent: Sat 3/24/2007 3:12 PM To: RXTX Developers and Users Subject: Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 8312 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20070324/f9e39c9b/attachment-0067.bin From greg.johnson at manchester.ac.uk Sun Mar 25 13:41:36 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Sun, 25 Mar 2007 21:41:36 +0200 Subject: [Rxtx] Mac intel weirdness Message-ID: Hi folks, I'm trying to get rxtx to work on my macbook pro with a USB-serial dongle on it. I am using the 2.1-8 code from the CVS (though it seems to report itself as 2.1-7: makes it difficult to prove to oneself that the changes have 'taken'! - line 4210 in SerialImp.c, line 40 in RXTXVersion.java) I am trying the 2.1-8 because of horrible lock problems in 2.1-7. However, the serialport closure code seems to be broken - it won't close because it believes the (previously opened!) port doesn't exist. Here is what I'm trying: 0. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "false" 1. Open a port Serialport serialport = (SerialPort) commportidentifier.open ("test",100); 2. Talk to a device ... 3. Close port serialport.close(); 4. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "true" - why is this? 5. Try to reopen port Serialport serialport2 = (SerialPort) commportidentifier.open("test", 100); throws PortInUseException. I've dug around a bit in the source, and it seems the SerialPort.close () should call the CommPortIdentifier.internalClosePort() (line 67 of CommPort.java). However, I crash out with the NoSuchPortException when getPortIdentifier is called. Which seems quite weird to me, seeing as it is called on this - which was create just beforehand. Does anyone know how to fix this? Cheers, greg From knute at frazmtn.com Sat Mar 24 10:32:38 2007 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 24 Mar 2007 09:32:38 -0700 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc>, Message-ID: <4604F036.17833.135298@knute.frazmtn.com> > >The behavior of timeout depends upon the setting of the threshold. Do you >have the threshold setting? > This is the same bug I reported last fall. There was a fellow that sent me an email asking if it had been fixed. I told him I didn't think so. He got somebody to write a fix for him but I have not been able to contact him again for the actual changes. The inaccurate timeout and the failure of blocking when no timeouts are set is a serious bug in my humble opinion and renders the software unusable for my applications. I'd really like to have an alternative to the Sun comm api but there just isn't one that I know of. -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Mar 26 16:17:00 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 26 Mar 2007 16:17:00 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> Message-ID: >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. From ra85551 at gmail.com Tue Mar 27 10:18:36 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Tue, 27 Mar 2007 20:18:36 +0400 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Ultimately I found a solution. At first, that wasn't actually the VMWare + WinXP + RXTX issue, that was WinXP + RXTX issue. But on pure XP it sometimes workes, sometimes not, while under VMWare I had never seen my snippet working at all. SimpleSnuV1.java would not help me, because there is only one line I missed, and SimpleSnuV1.java also doesn't contain it! It is as follows: serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_OUT | SerialPort.FLOWCONTROL_RTSCTS_IN); Thank you for your attention. -- Pavel Parkhomenko From griff at op.pl Wed Mar 28 01:28:19 2007 From: griff at op.pl (griff@op.pl) Date: Wed, 28 Mar 2007 09:28:19 +0200 Subject: [Rxtx] No blocking read on Windows. Message-ID: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/5d07d571/attachment-0064.html -------------- next part -------------- Hi, I have problem that InputStram.read() (SerialPort)?returns -1 instead blocking and waiting for data. I found that this problem was ?known in 2005 : ? >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > >> Hi Trent >> >> Thanks for the fast response. >> Here's a Q&D test program for the blocking read on windows that just >> attempts to read one byte, and prints the resulting byte. On my system it >> returns -1, where I expect that it keeps waiting for data. >> >This isn't happening on Linux so the bug is in src/termios.c.? I'll have >something this weekend to fix that. I'm using RXTX 2.1.7r2 and the problem still is here. Im using Windows XP and java 1.5 disableReciveTimeout() and disableReciveTreshhold() dont help. ? best regards ? Piotr Zielniok From Adrien.TOS at ingenico.com Wed Mar 28 01:40:46 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Wed, 28 Mar 2007 09:40:46 +0200 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903E88880@frsnprexc1.usr.ingenico.loc> Looking at the code, it seems there is no support for infinite timeout? And maybe the count++ < 20 condition is breaking out of the loop too early? The only condition to break out of the loop should either be the timeout has expired or the number of requested bytes has been received. -----Message d'origine----- De : rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] De la part de Trent Jarvi Envoy? : mardi 27 mars 2007 00:17 ? : RXTX Developers and Users Objet : Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From j.kenneth.gentle at acm.org Wed Mar 28 06:44:15 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 28 Mar 2007 08:44:15 -0400 Subject: [Rxtx] No blocking read on Windows. In-Reply-To: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> References: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> Message-ID: <200703281844.l2SIiITW028614@qbang.org> Just another "ME TOO!" - I'm seeing this problem on Windows XP, jre for windows XP/Embedded. I cranked receiveTimeout up to Integer.MAX_INT, but it doesn't seem to wait that long At 03:28 2007-03-28, you wrote: >Hi, >I have problem that InputStram.read() (SerialPort) returns -1 >instead blocking and waiting for data. I found that this problem >was known in 2005 : > > >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > > > >> Hi Trent > >> > >> Thanks for the fast response. > >> Here's a Q&D test program for the blocking read on windows that just > >> attempts to read one byte, and prints the resulting byte. On my system it > >> returns -1, where I expect that it keeps waiting for data. > >> > > >This isn't happening on Linux so the bug is in src/termios.c. I'll have > >something this weekend to fix that. > >I'm using RXTX 2.1.7r2 and the problem still is here. >Im using Windows XP and java 1.5 >disableReciveTimeout() and disableReciveTreshhold() dont help. > >best regards > >Piotr Zielniok > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From greg.johnson at manchester.ac.uk Wed Mar 28 14:43:29 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Wed, 28 Mar 2007 22:43:29 +0200 Subject: [Rxtx] Cannot close and reopen serial port Message-ID: <377F9765-7A9D-4CE9-9176-FFB63A2594F0@manchester.ac.uk> Dear all, It appears I cannot close a port properly: SerialPort serialport = portid.open("myprog",100); // do some stuff, all works fine serialport.close(); // all seems fine but... SerialPort sp2 = portid.open("myprog",100); throws PortInUseException. And when I dig into the rxtx code, I find in CommPort.java, in close(): CommPortIdentifier cp = CommPortIdentifier.getPortIdentifier(this); (line 64 or there abouts) but this throws a NoSuchPortException which is caught but ignored (line 74ish). Can anyone suggest how this could happen: a port that was valid, opened, and used, throws a NSPE when it comes to closing it? I'm pulling my (remaining) hair out over this one! Cheers, greg PS And thanks for RXTX - it's great to have! PPS (21.-7. winxp/osx both, java 1.5) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/c28852fc/attachment-0063.html From rxtx at vrijheidslaan.net Fri Mar 30 16:52:50 2007 From: rxtx at vrijheidslaan.net (Rob) Date: Fri, 30 Mar 2007 22:52:50 -0000 Subject: [Rxtx] Cvs Question Message-ID: <61896.80.126.150.87.1175295162.squirrel@webmail.provalue.nl> Hi There, Im trying to get the latest version to work on mac osx. Problem is that i can't checkout version 2.1.8. Probably my fault but can some one please give me the alternative commands for: [user at myhost]$ export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot [user at myhost]$ cvs login Thanx, Rob From ra85551 at gmail.com Thu Mar 1 03:47:06 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Thu, 1 Mar 2007 13:47:06 +0300 Subject: [Rxtx] enableReceiveTimeout() issue Message-ID: Hello, world! I found a limitation of 16300 ms for CommPort's enableReceiveTimeout() method, while in original javax.comm docs there are no any references to that. Is that a bug or feature? I actually need longer timeouts sometimees. -- Pavel Parkhomenko From lyon at docjava.com Thu Mar 1 07:54:17 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 01 Mar 2007 09:54:17 -0500 Subject: [Rxtx] parametric singleton design pattern In-Reply-To: References: <22d55aea0702081207q5e7f6785l352d498d6f5f9fb1@mail.gmail.com> <22d55aea0702100034o3bcf42f3j1d1a6257029a67b0@mail.gmail.com> Message-ID: Hi All, I have been thinking about the use of a design pattern to cache resources that are consumed by processes. Toward that end, I have arrived at a parametric singleton design pattern, which I mentioned on this list some time ago. The idea has been published at: http://www.jot.fm/issues/issue_2007_03/column2 I can't help but think that there should be an API available for dealing with the tracking of serial port usage. Perhaps it is a kind of resource manager called the: SerialPortManager basic prototypes already exist in this vain. See, for example: http://www.ce.rit.edu/research/projects/2005_fall/rt_poolsystem/doc/PoolMon/SerialPortManager.html http://www.eventhelix.com/RealtimeMantra/PatternCatalog/serial_port_design_pattern.htm And others shown by a google search on "SerialPortManager" Cheers! - Doug From Eric.Arseneau at sun.com Thu Mar 1 10:15:03 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:15:03 -0800 Subject: [Rxtx] Any known Java 6 issues with RXTX 2.1-7r2 ? Message-ID: <45E70A17.1060206@sun.com> I just did a test on a recent build of Solaris 11 x86 and it seems that I can connect to my serial device fine when Java 5 is the default, but when Java 6 is the default, no go. Any information ? From Eric.Arseneau at sun.com Thu Mar 1 10:19:58 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:19:58 -0800 Subject: [Rxtx] Mac OS X and missing data Message-ID: <45E70B3E.7040908@sun.com> We have a device which is USB based but presents itself as a serial port to a machine. On my MacBook Pro I can get excellent throughput if I get my device to send data as quickly as possible. On the desktop side, if I do an type of disk IO to log the data I get, I end up with some missing data at some point. I hooked up a USB analyzer and did confirm that all the data is sent as expected to the desktop from the device. I found a work around for this, buffer the data in memory and only write the data out when I've received it all. However, when the same code and same device is attempted on a co-workers MacBook Pro (same hardware specs), I get errors and must slow down dramatically the device side's sending of data. Any ideas/recommendations on what I can do to get rid of this error ? From what I can tell, it seems that RXTX is not able to wake up to the interrupts coming in indicating data is ready, quickly enough, is there anything I can do ? From chinkaiw at hotmail.com Fri Mar 2 00:57:43 2007 From: chinkaiw at hotmail.com (Wang Chinkai) Date: Fri, 02 Mar 2007 07:57:43 +0000 Subject: [Rxtx] dynamic detect rs232 port Message-ID: Hi all I have a question about detecting rs232 port dynamicly. I have to aceess some port and detect rs232 port at the same time. Some usb device simulates rs232 port , and I can not know what the port name it gets until it connects,so I have to detect it dynamic,but I have to access another rs232 device at the same time. I found a problem. If I use CommPortIdentifier.getPortIdentifiers() to get new port list , and the other rs232 access function will not close port correctly. So , How can I solve it . Thanks. _________________________________________________________________ ?? 2GB ???? Windows Live Mail ????????????? http://ideas.live.com/programpage.aspx?versionid=5d21c51a-b161-4314-9b0e-4911fb2b2e6d From eu259473 at tele2.it Fri Mar 2 06:16:40 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 02 Mar 2007 14:16:40 +0100 Subject: [Rxtx] rxtx on HP tru 64 unix Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070302/706c7a70/attachment-0091.html From tjarvi at qbang.org Fri Mar 2 08:39:33 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 08:39:33 -0700 (MST) Subject: [Rxtx] rxtx on HP tru 64 unix In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, "Giuseppe Marchese" wrote: > Hi > > I try to install rxtx on hp tru 64 but make fails, > There are somebody that do the same and work. > > > Sorry for may english! > > Hi Giuseppe Could you provide a log of the failure? script ./configure make # use gnu make exit The information will be in the typescript created. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 2 19:56:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 19:56:52 -0700 (MST) Subject: [Rxtx] dynamic detect rs232 port In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, Wang Chinkai wrote: > Hi all > > I have a question about detecting rs232 port dynamicly. > > I have to aceess some port and detect rs232 port at the same time. > Some usb device simulates rs232 port , and I can not know > what the port name it gets until it connects,so I have to detect it > dynamic,but I have to access > another rs232 device at the same time. > > I found a problem. Hi Wang This is a known problem. The code is braindead there. In fact there needs to be events even in a rudamentary way when you add a usb dongle. I'm burried in tasks not far from rxtx but not in rxtx. I can't get to the problem but we would accept patches if you dig into it. [I'm getting to the license question earlier too; I don't have another 10%] -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Fri Mar 2 23:19:01 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 01:19:01 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Hi, Under ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable USB -> serial converter(using virtual com port drivers), with using example code pretty much straight out of http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port opens fine, enumerations all work, etc. My application calls for a large amount of data to be transferred in a short amount of time at 2,000,000 baud. My hardware sends approximately 15,232 bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL converter work fine, and the application works using C++. In C++, I do a hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); to open the port, and a boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); to read the port. The variable buffer fills with the 15238 bytes, and returns. If I do a resultz = is.read(cbuf,0,15238); in java with RXTX where is = new BufferedReader(new InputStreamReader(port.getInputStream())); and where resultz is an int, and cbuf is a char [] cbuf, resultz gets EXACTLY 3968 bytes the first time called. If I call it multiple times, I get roughly 11k total(less than what is sent), never more than the 3968 bytes per is.read() call. My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 bytes. I've played with inputbuffersize, receive threshold, receivetimeout, and so on. The FTDI virtual com port drivers that I'm using are rock solid, and have had zero problems with them using a variety of applications, some of my own, some professionally written, etc. No flow control is used anyplace, no RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. No exceptions are being thrown. What am I doing wrong, and what I can adjust to receive the full 15k bytes in one single read? Thanks! Keith From Eric.Arseneau at sun.com Fri Mar 2 23:32:07 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Fri, 02 Mar 2007 22:32:07 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <45E91667.20501@sun.com> This is the same type of thing that is happening to me on Mac OS X and does not seem to behave the same on different machines. I posted a day or two ago on this with subject "Mac OS X and missing data". Would love to hear if there is a solution to this :) From tjarvi at qbang.org Sat Mar 3 10:54:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 10:54:17 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > Hi, > > Under > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable > USB -> serial converter(using virtual com port drivers), with using example > code pretty much straight out of > http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port > opens fine, enumerations all work, etc. > > My application calls for a large amount of data to be transferred in a short > amount of time at 2,000,000 baud. My hardware sends approximately 15,232 > bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL > converter work fine, and the application works using C++. > > In C++, I do a > > hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, > OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); > > to open the port, and a > > boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); > > to read the port. > > The variable buffer fills with the 15238 bytes, and returns. > > If I do a > > resultz = is.read(cbuf,0,15238); in java with RXTX > > where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > > and where resultz is an int, and cbuf is a char [] cbuf, resultz gets > EXACTLY 3968 bytes the first time called. If I call it multiple times, I get > roughly 11k total(less than what is sent), never more than the 3968 bytes > per is.read() call. > > My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 > bytes. > > I've played with inputbuffersize, receive threshold, receivetimeout, and so > on. The FTDI virtual com port drivers that I'm using are rock solid, and > have had zero problems with them using a variety of applications, some of my > own, some professionally written, etc. No flow control is used anyplace, no > RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. > > No exceptions are being thrown. > > What am I doing wrong, and what I can adjust to receive the full 15k bytes > in one single read? > > Thanks! > Hi Keith I would expect a 20 meg application is going to have different behavior with the OS than a smaller application with respect to the kernel memory managment, schedualing, ... Something subtle could be causing problems. With respect to the recieve timeout and threshold, if you set the timeout to zero and the threshold to the size of data you expect, read should not return until it get that data. You may try with a stand alone application that tests just that with the C/C++ API. If the read is returning with less data when tested for short reads, you have found a bug in the device driver more than likely. The USB dongle vendor would probably be interested in knowing about this. As mentioned, these devices are getting very good; almost bug free. I suspect you found a bug though if you did use the threshold and timeout properly. The missing data is typical when not using flow control. When the OS buffering fills, the hardware will start dropping bytes. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:38:52 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:38:52 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> update: I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now instead of 3968. This makes sense. 128 bytes of overhead + 3968 bytes of data = 4096 transfer size 32 bytes of overhead + 992 bytes of data = 1024 transfer size. 1/4 the data = 1/4 the overhead. I rearranged my reading like so: resultz = is.read(cbuf,0,3968); resultz = is.read(cbuf,3968,3968); resultz = is.read(cbuf,7936,3968); while (!(is.ready())); // wait for ready resultz = is.read(cbuf,11904,3334); and this grabs 15,238 bytes total. BUT, I still have the quandry of the screwed up multi-bytes. I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. Approx 8% of the data. The bad bytes always seem to take the flavor of 0x2018, 0x2019, x2022, x2030, x201d. Are these maybe errors and I don't know what they enumerate to? I still can't believe some other layer isn't handling putting those bytes together all in one stream for me. Thanks Keith ----- Original Message ----- From: "Keith" To: "Bob Jacobsen" ; "RXTX Developers and Users" Sent: Saturday, March 03, 2007 11:26 AM Subject: Re: [Rxtx] is.read() only returning 3968 bytes > Bob, > > > Interesting numerical coincidence is that (max USB transfer) - (what > > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > > needed to transfer that much data. > > I was thinking along the same lines. I don't know USB well, but I do know > that those numbers were close enough to warrant investigating the > relationship between them. > > > I think what you're seeing is the internal buffering of the USB data > > stream. You'll need some form of higher-level buffering to smooth > > that out. > > Shouldn't the InputStreamReader() and BufferedReader() provide this type of > buffering? Isn't that the idea behind those? > > > All hypotheses need to be tested. In this case, a test would be to > > check for missing data. If this idea is right, you'll get _all_ the > > data, but you won't be missing characters. > > I did start looking at the data. -- I'm getting weird results. > > I tried this: > > loopzz = 0; > > for (looptwo = 0; looptwo < 100000; looptwo++) { > while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > > }} > > So I'm reading one character at a time. The good news is that loopzz is > exactly 15238 at the end of the routine, which is perfectly correct. I > picked looptwo value out of thin air. > > The weird results come in terms of the values, the data isn't correct at > least in one case. Look here: > > 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > > This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). > But the 0x89 was replaced by 0x2030. Why the heck would the returned value > be 0x2030?? Why is the returned byte completely out of range? Why the > multibyte return? > > From InputStream in the API: > > read > public abstract int read() > throws IOExceptionReads the next byte of data from the > input stream. The value byte is returned as an int in the range 0 to 255. If > no byte is available because the end of the stream has been reached, the > value -1 is returned. This method blocks until input data is available, the > end of the stream is detected, or an exception is thrown. > Value should be 0-255. > > > In my application time is really critical, reading 1 byte at a time is > probably not going to work. > > Thanks Eric & Bob for looking at this. > > Keith > From tjarvi at qbang.org Sat Mar 3 12:52:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 12:52:27 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > update: > > I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now > instead of 3968. > > This makes sense. > > 128 bytes of overhead + 3968 bytes of data = 4096 transfer size > 32 bytes of overhead + 992 bytes of data = 1024 transfer size. > > 1/4 the data = 1/4 the overhead. > > I rearranged my reading like so: > > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. > Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? > > I still can't believe some other layer isn't handling putting those bytes > together all in one stream for me. > The layer for this in Serial land is flow control. Software and hardware flow control prevent the overruns you observe. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:54:41 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:54:41 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <001a01c75dcd$c8802a70$6600a8c0@jbh757ktruws7g> Trent, Thanks for taking the time to reply. > I would expect a 20 meg application is going to have different behavior > with the OS than a smaller application with respect to the kernel memory > managment, schedualing, ... Something subtle could be causing problems. Well, at least I know the VCP drivers, the OS, etc can handle 2mbps reliably. Without hiccuping or dropping bytes. The C++ code works reliably without flow control. > The missing data is typical when not using flow control. When the OS > buffering fills, the hardware will start dropping bytes. I'm actually not getting MISSING data, I'm getting CORRUPTED data. If you look at my most recent post, I'm getting these bad bytes in place of the correct values: 0x2018, 0x2019, x2022, x2030, x201d. Why would is.read() return values not in the range of 0-255 ? Thanks. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 08:59:14 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 07:59:14 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: At 1:19 AM -0500 3/3/07, Keith wrote: >If I do a > >resultz = is.read(cbuf,0,15238); in java with RXTX > >where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > >and where resultz is an int, and cbuf is a char [] cbuf, resultz gets >EXACTLY 3968 bytes the first time called. If I call it multiple times, I get >roughly 11k total(less than what is sent), never more than the 3968 bytes >per is.read() call. > >My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 >bytes. Interesting numerical coincidence is that (max USB transfer) - (what you get) = 4096-3968 = 128 bytes is (almost) the size of the headers needed to transfer that much data. I think what you're seeing is the internal buffering of the USB data stream. You'll need some form of higher-level buffering to smooth that out. All hypotheses need to be tested. In this case, a test would be to check for missing data. If this idea is right, you'll get _all_ the data, but you won't be missing characters. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 09:26:14 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 11:26:14 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Bob, > Interesting numerical coincidence is that (max USB transfer) - (what > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > needed to transfer that much data. I was thinking along the same lines. I don't know USB well, but I do know that those numbers were close enough to warrant investigating the relationship between them. > I think what you're seeing is the internal buffering of the USB data > stream. You'll need some form of higher-level buffering to smooth > that out. Shouldn't the InputStreamReader() and BufferedReader() provide this type of buffering? Isn't that the idea behind those? > All hypotheses need to be tested. In this case, a test would be to > check for missing data. If this idea is right, you'll get _all_ the > data, but you won't be missing characters. I did start looking at the data. -- I'm getting weird results. I tried this: loopzz = 0; for (looptwo = 0; looptwo < 100000; looptwo++) { while (is.ready()) { cbuf[loopzz] = (char) is.read(); loopzz++; }} So I'm reading one character at a time. The good news is that loopzz is exactly 15238 at the end of the routine, which is perfectly correct. I picked looptwo value out of thin air. The weird results come in terms of the values, the data isn't correct at least in one case. Look here: 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). But the 0x89 was replaced by 0x2030. Why the heck would the returned value be 0x2030?? Why is the returned byte completely out of range? Why the multibyte return? >From InputStream in the API: read public abstract int read() throws IOExceptionReads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown. Value should be 0-255. In my application time is really critical, reading 1 byte at a time is probably not going to work. Thanks Eric & Bob for looking at this. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 14:44:50 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 13:44:50 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: Java's "char" type is Unicode. I think what you're seeing is a bug in the byte -> Unicode translation. 0x2018, 0x2019 are the curly open and close quotes. There used to be (and might still be) bugs in the conversion of these in a couple of libc versions. Some of the ASCII -> ISO and ISO -> ASCII routines were a little over-ambitious with respect to handling the open and close quotes, and tried to convert them to the "curly" form inappropriately. Try _not_ casting it to char. Bob At 11:26 AM -0500 3/3/07, Keith wrote: >Bob, > >> Interesting numerical coincidence is that (max USB transfer) - (what >> you get) = 4096-3968 = 128 bytes is (almost) the size of the headers >> needed to transfer that much data. > >I was thinking along the same lines. I don't know USB well, but I do know >that those numbers were close enough to warrant investigating the >relationship between them. > >> I think what you're seeing is the internal buffering of the USB data >> stream. You'll need some form of higher-level buffering to smooth >> that out. > >Shouldn't the InputStreamReader() and BufferedReader() provide this type of >buffering? Isn't that the idea behind those? > >> All hypotheses need to be tested. In this case, a test would be to >> check for missing data. If this idea is right, you'll get _all_ the >> data, but you won't be missing characters. > >I did start looking at the data. -- I'm getting weird results. > >I tried this: > >loopzz = 0; > >for (looptwo = 0; looptwo < 100000; looptwo++) { >while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > >}} > >So I'm reading one character at a time. The good news is that loopzz is >exactly 15238 at the end of the routine, which is perfectly correct. I >picked looptwo value out of thin air. > >The weird results come in terms of the values, the data isn't correct at >least in one case. Look here: > >0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > >This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). >But the 0x89 was replaced by 0x2030. Why the heck would the returned value >be 0x2030?? Why is the returned byte completely out of range? Why the >multibyte return? > >>From InputStream in the API: > >read >public abstract int read() > throws IOExceptionReads the next byte of data from the >input stream. The value byte is returned as an int in the range 0 to 255. If >no byte is available because the end of the stream has been reached, the >value -1 is returned. This method blocks until input data is available, the >end of the stream is detected, or an exception is thrown. >Value should be 0-255. > > >In my application time is really critical, reading 1 byte at a time is >probably not going to work. > >Thanks Eric & Bob for looking at this. > >Keith > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 15:10:11 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 17:10:11 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Bob said ..... > Java's "char" type is Unicode. I think what you're seeing is a bug > in the byte -> Unicode translation. Bob -- I think you hit the nail on the head. I was just coming to the same realization here. I knew that something funny was going on because the same bytes always got "corrupted." I'm pretty sure its in the InputStreamReader() functionality where the conversion junk is happening. Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. I don't know if simply changing the cast is going to work. Since the conversion is happening upstream (pun intended), I don't think my cast is doing this. Also I think the compiler forced me to use the cast. I'm still playing around, and I'll report back once I nail it down. Thanks!! Keith From tjarvi at qbang.org Sat Mar 3 15:59:46 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 15:59:46 -0700 (MST) Subject: [Rxtx] Win64 rxtx Testers? Message-ID: I have compiled win64 binaries of rxtx. Are there any users interested in testing them? If so, I'll look into putting them on the web site. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Mar 3 15:35:06 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 14:35:06 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: Because of this and similar problems, JMRI does all it's serial IO using +only+ byte values. It's a but of a pain, as Java wants to go to char and int types a little too aggressively, but it does solve the "uncontrolled conversions" problems. Bob At 5:10 PM -0500 3/3/07, Keith wrote: >Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > >Bob -- I think you hit the nail on the head. > >I was just coming to the same realization here. I knew that something funny >was going on because the same bytes always got "corrupted." > >I'm pretty sure its in the InputStreamReader() functionality where the >conversion junk is happening. > >Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > >I don't know if simply changing the cast is going to work. Since the >conversion is happening upstream (pun intended), I don't think my cast is >doing this. Also I think the compiler forced me to use the cast. -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mark at mdsh.com Sun Mar 4 11:01:33 2007 From: mark at mdsh.com (Mark Himsley) Date: Sun, 04 Mar 2007 18:01:33 +0000 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: <5C01AC72C200388815C04982@bedroom.mdsh.local> On 03 March 2007 14:38 -0500 Keith wrote: > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT > consistent. Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? It looks like you need to use DataInputStream and DataOutputStream. -- Mark Himsley From tjarvi at qbang.org Sun Mar 4 11:35:08 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 11:35:08 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" > > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > > * Line #21 - Not sure if you need a (TM) mark for > the term "Sun" > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > OK. I'm going through this today. Some groups ask if rxtx could be under their license also. I think this is a good example of why I resist multiple licenses and focus on why the current license may not be usable by them. The RXTX project is a convergence of hobby and commercial interests. I happen to do both right now. The problem with licensing is we have to stay on top of them as they change. Clearly, adding more licenses will not make this easier. I'm acting as the hobby person today. RXTX always favors the hobby people. But as we move forward, I'm going to need to bring this to lawyers at work and explain to them what is going on. Others here may have to do this also. I don't anticipate problems or unexpected changes. The goal is a consistant, comprehendable and usable license as close to what we have now as possible. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 14:52:10 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 14:52:10 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (1/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: I'm breaking this into two parts. I expect the second part will need more attention. Comments first, then the changed material below. On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > Thanks > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. OK. RXTX for consitent use. java should not be capitalized because it does not only mean Sun [TM] Java [TM]. An example of this not meaning Java is when people use RXTX with GCJ. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". There are not any contributors that are in all of RXTX yet but I did update the comment to try to reflect the current situation without making it a nightmare to maintain. I looked to see how the Linux kernel does it as a reference point. > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" The URL can be problematic. I have done so below with a time reference. GNU does not provide version information in their URLS. I picture this being a problem when the version 3 comes out. > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > This will be corrected when the copy is updated to the version linked below. ---------------- begin proposed material involved -------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. ----------------- end proposed material involved -------------------- I'll be looking at the linking issue again next. That should be all that remains other than including the 2.1 version. Let me know if you have problems with anything here. I do not want to dilute the material I post next with these housekeeping tasks. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 16:08:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 16:08:36 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: For those that are wondering what is going on here, this next bit is the meat of the changes. We agreed a long time ago to put this disclaimer in. We did a so so job. It was in rxtx 2.0, not well written, ... So some groups using rxtx that would like to ship rxtx so users don't need to download, install, go to the mail-list to find why it failed, ... Then their legal teams tell them section 5 paragraph 2 is a show stopper. That was never the intent. Now going through what remains... > and might need a (TM) suffix to make Sun happy. Added disclaimer at the ended 'all trademarks belong...' > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. OK. As you can see I was trying to adjust GNU text there for the LGPL. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. used dynamically linked terminology. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". I tried to address this more upfront with an intent statement. Let me know if you have problems with it. I also tried to make it a little more clear what was derived from the GNU solution by moving the link location closer to GNU's suggestion. > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > Thats the intent. Here is the combined fixes. Note that only the material in /*-- --*/ is being touched. The new GPL license is there but unmodified. ------------------------ begin proposed new license ------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. | | An executable that contains no derivative of any portion of RXTX, but | is designed to work with RXTX by being dynamically linked with it, | is considered a "work that uses the Library" subject to the terms and | conditions of the GNU Lesser General Public License. | | The following has been added to the RXTX License to remove | any confusion about linking to RXTX. We want to allow in part what | section 5, paragraph 2 of the LGPL does not permit in the special | case of linking over a controlled interface. The intent is to add a | Java Specification Request or standards body defined interface in the | future as another exception but one is not currently available. | | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface | | As a special exception, the copyright holders of RXTX give you | permission to link RXTX with independent modules that communicate with | RXTX solely through the Sun Microsytems CommAPI interface version 2, | regardless of the license terms of these independent modules, and to copy | and distribute the resulting combined work under terms of your choice, | provided that every copy of the combined work is accompanied by a complete | copy of the source code of RXTX (the version of RXTX used to produce the | combined work), being distributed under the terms of the GNU Lesser General | Public License plus this exception. An independent module is a | module which is not derived from or based on RXTX. | | Note that people who make modified versions of RXTX are not obligated | to grant this special exception for their modified versions; it is | their choice whether to do so. The GNU Lesser General Public License | gives permission to release a modified version without this exception; this | exception also makes it possible to release a modified version which | carries forward this exception. | | You should have received a copy of the GNU Lesser General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA | All trademarks belong to their respective owners. --------------------------------------------------------------------------*/ The original GNU Lesser General Public License Follows. GNU LESSER GENERAL PUBLIC LICENSE Version 2.1, February 1999 Copyright (C) 1991, 1999 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. [This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence the version number 2.1.] Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This license, the Lesser General Public License, applies to some specially designated software packages--typically libraries--of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below. When we speak of free software, we are referring to freedom of use, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish); that you receive source code or can get it if you want it; that you can change the software and use pieces of it in new free programs; and that you are informed that you can do these things. To protect your rights, we need to make restrictions that forbid distributors to deny you these rights or to ask you to surrender these rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library or if you modify it. For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights. We protect your rights with a two-step method: (1) we copyright the library, and (2) we offer you this license, which gives you legal permission to copy, distribute and/or modify the library. To protect each distributor, we want to make it very clear that there is no warranty for the free library. Also, if the library is modified by someone else and passed on, the recipients should know that what they have is not the original version, so that the original author's reputation will not be affected by problems that might be introduced by others. Finally, software patents pose a constant threat to the existence of any free program. We wish to make sure that a company cannot effectively restrict the users of a free program by obtaining a restrictive license from a patent holder. Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license. Most GNU software, including some libraries, is covered by the ordinary GNU General Public License. This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs. When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library. We call this license the "Lesser" General Public License because it does Less to protect the user's freedom than the ordinary General Public License. It also provides other free software developers Less of an advantage over competing non-free programs. These disadvantages are the reason we use the ordinary General Public License for many libraries. However, the Lesser license provides advantages in certain special circumstances. For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License. In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software. For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU operating system, as well as its variant, the GNU/Linux operating system. Although the Lesser General Public License is Less protective of the users' freedom, it does ensure that the user of a program that is linked with the Library has the freedom and the wherewithal to run that program using a modified version of the Library. The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, whereas the latter must be combined with the library in order to run. GNU LESSER GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License Agreement applies to any software library or other program which contains a notice placed by the copyright holder or other authorized party saying it may be distributed under the terms of this Lesser General Public License (also called "this License"). Each licensee is addressed as "you". A "library" means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables. The "Library", below, refers to any such software library or work which has been distributed under these terms. A "work based on the Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term "modification".) "Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library. Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does. 1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) The modified work must itself be a software library. b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change. c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License. d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful. (For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library. In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. 4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange. If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code. 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables. When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law. If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.) Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself. 6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications. You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things: a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.) b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. c) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution. d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place. e) Verify that the user has already received a copy of these materials or that you have already sent this user a copy. For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute. 7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things: a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above. b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work. 8. You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 9. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Library (or any work based on the Library), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Library or works based on it. 10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties with this License. 11. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply, and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 12. If the distribution and/or use of the Library is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Library under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 13. The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation. 14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Libraries If you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the ordinary General Public License). To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Also add information on how to contact you by electronic and paper mail. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the library, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the library `Frob' (a library for tweaking knobs) written by James Random Hacker. , 1 April 1990 Ty Coon, President of Vice That's all there is to it! ------------------------ end of proposed license ------------------ -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sun Mar 4 16:26:04 2007 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 04 Mar 2007 17:26:04 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <45EB558C.3010609@cox.net> Bob Jacobsen wrote: > Because of this and similar problems, JMRI does all it's serial IO > using +only+ byte values. It's a but of a pain, as Java wants to go > to char and int types a little too aggressively, but it does solve > the "uncontrolled conversions" problems. Anytime that you are reading bytes of data that is not printable, unicode text, in Java, you really need to stay away from the Readers. Use input stream only, or you will see unicode valued byte groups converted to unicode "char" values. Gregg Wonderly From joachim at buechse.de Mon Mar 5 04:23:48 2007 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 5 Mar 2007 12:23:48 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> The behaviour is exactly what you asked for in you code. is = new BufferedReader(new InputStreamReader(port.getInputStream())); Readers return Text (ie unicode chars) not bytes. You instantiate the InputStreamReader without saying which charset you want, which means "platform default". As this is on Windows, it will convert Windows characters to equivalent unicode characters. If you want to read bytes, read bytes not Text. Reading bytes is done with InputStream and BufferedInputStream. BTW: The InputStream and Reader methods that read arrays are not guarenteed to fill up the array. You always have to check what you really got, and advance your index accordingly. A typical "read up to 32k" method looks like this: InputStream is= ... // -- determine the max buffer size int len= is.available(); if (len == 0) { len= 32 * 1024; } // -- read all available data byte[] buffer= new byte[len]; int pos= 0; int read; do { read= is.read(buffer, pos, buffer.length - pos); pos= pos + read; } while (read != -1 && pos < buffer.length); Best regards, Joachim --- Joachim B?chse Phone: +41 44 500 2604 Buechse Consulting Hadlaubsteig 2 CH-8006 Z?rich On 03.03.2007, at 23:10, Keith wrote: > Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > > Bob -- I think you hit the nail on the head. > > I was just coming to the same realization here. I knew that > something funny > was going on because the same bytes always got "corrupted." > > I'm pretty sure its in the InputStreamReader() functionality where the > conversion junk is happening. > > Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > > I don't know if simply changing the cast is going to work. Since the > conversion is happening upstream (pun intended), I don't think my > cast is > doing this. Also I think the compiler forced me to use the cast. > > I'm still playing around, and I'll report back once I nail it down. > > Thanks!! > > Keith > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Mon Mar 5 07:25:46 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 05 Mar 2007 08:25:46 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> Message-ID: <45EC286A.8060608@cox.net> Joachim Buechse wrote: > BTW: The InputStream and Reader methods that read arrays are not > guarenteed to fill up the array. You always have to check what you > really got, and advance your index accordingly. A typical "read up to > 32k" method looks like this: > > InputStream is= ... > // -- determine the max buffer size > int len= is.available(); > if (len == 0) { > len= 32 * 1024; > } > // -- read all available data > byte[] buffer= new byte[len]; > int pos= 0; > int read; > do { > read= is.read(buffer, pos, buffer.length - pos); > pos= pos + read; > } while (read != -1 && pos < buffer.length); > My preferred structure is. byte arr[ len ]; int cnt; int off = 0; while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { off += cnt; } This keeps you from adding -1 to pos when the read returns -1. It also skips out when the read is 0 bytes which, is not a described EOF in InputStream java docs, but is a condition I want to be aware of. Gregg Wonderly From joachim at buechse.de Tue Mar 6 02:52:58 2007 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 6 Mar 2007 10:52:58 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <45EC286A.8060608@cox.net> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: The code I copied was from a file resource reader, it shouldn't really be applied to networking/external IO code. Mea culpa. However aborting when you get 0 from read is not always what you want either (you kind of indicated that already). Some unix java implementations will return 0 if the kernel read was aborted with EINTER, which is rarely the point where you want to abort your read - at least not without further checks. A "complete" solution always depends on the events you need to handle and the time the total read could take in reality. In some cases it's worth checking Thread.isInterrupted() in the loop, some code re-loops on 0 but only a limited number of times, some check a total timeout limit, etc... Best regards, Joachim On 05.03.2007, at 15:25, Gregg Wonderly wrote: > My preferred structure is. > > byte arr[ len ]; > int cnt; > int off = 0; > while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { > off += cnt; > } > > This keeps you from adding -1 to pos when the read returns -1. It > also skips > out when the read is 0 bytes which, is not a described EOF in > InputStream java > docs, but is a condition I want to be aware of. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Mar 6 14:47:44 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 Mar 2007 14:47:44 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: Just FYI, rxtx will usually not break out on EINTER. The code in the native library usually does something close to this: do { read(...) } while ( !done && errno==EINTR ); Obviously there is a little more involved but it will retry on EINTER if not done. On Tue, 6 Mar 2007, Joachim Buechse wrote: > The code I copied was from a file resource reader, it shouldn't > really be applied to networking/external IO code. Mea culpa. > > However aborting when you get 0 from read is not always what you want > either (you kind of indicated that already). Some unix java > implementations will return 0 if the kernel read was aborted with > EINTER, which is rarely the point where you want to abort your read - > at least not without further checks. A "complete" solution always > depends on the events you need to handle and the time the total read > could take in reality. In some cases it's worth checking > Thread.isInterrupted() in the loop, some code re-loops on 0 but only > a limited number of times, some check a total timeout limit, etc... > > Best regards, > Joachim > > On 05.03.2007, at 15:25, Gregg Wonderly wrote: >> My preferred structure is. >> >> byte arr[ len ]; >> int cnt; >> int off = 0; >> while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { >> off += cnt; >> } >> >> This keeps you from adding -1 to pos when the read returns -1. It >> also skips >> out when the read is 0 bytes which, is not a described EOF in >> InputStream java >> docs, but is a condition I want to be aware of. >> >> Gregg Wonderly >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 gjhanna at gmail.com Thu Mar 8 13:42:52 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Fri, 9 Mar 2007 09:42:52 +1300 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? Message-ID: I've just struck an issue using rxtx in a multi-threaded environment: If I have 3 threads trying to open *the same* comm-port I get a deadlock in CommPortIdentifier.open If I have just 2, it works fine - I get a PortInUseException which is nice and I can handle it. The 3 thread->deadlock thing is causing me issues. (Sample code below). This is from the java thread-dump Found one Java-level deadlock: ============================= "Thread-2": waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object ), which is held by "Thread-1" "Thread-1": waiting to lock monitor 0x0003e9cc (object 0x2450e108, a gnu.io.CommPortIdentifier), which is held by "Thread-2" Java stack information for the threads listed above: =================================================== "Thread-2": at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:329) - waiting to lock <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) "Thread-1": at java.lang.Object.wait(Native Method) - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) - locked <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) (Apart from this, rxtx is working fantastically for us). I'm thinking I'll have to implement some sort of locking mechanism that *doesn't* use java synchronization to prevent this situation. (Which doesn't sound like a good idea to me). Any ideas? Thanks, Greg Hanna ============= RXTXLockTest.java ======================================== import gnu.io.CommPort; import gnu.io.CommPortIdentifier; /** * @author Greg Hanna * Minimal code to create a deadlock with rxtx in multithreaded open */ public class RXTXLockTest { public static void main(String[] args) { try { CommPortIdentifier cpiCom1 = CommPortIdentifier.getPortIdentifier ("COM14"); OpenThread t1 = new OpenThread (" one ", cpiCom1); OpenThread t2 = new OpenThread (" two ", cpiCom1); OpenThread t3 = new OpenThread (" 003 ", cpiCom1); t1.start(); t2.start(); t3.start(); // comment this out and it runs with (expected) PortInUseException } catch (Exception e) { e.printStackTrace(); } } } class OpenThread extends Thread { String name; CommPortIdentifier cpi; CommPort cp; public OpenThread (String name, CommPortIdentifier cpi) { this.name = name; this.cpi = cpi; System.out.println (System.currentTimeMillis() + name + " thread created"); } public void run () { try { System.out.println (System.currentTimeMillis() + name + " opening"); cp = cpi.open(name, 2000); System.out.println (System.currentTimeMillis() + name + " opened - sleeping"); sleep (2000); // do the serial comms with the device. System.out.println (System.currentTimeMillis() + name + " slept - closing"); cp.close(); System.out.println (System.currentTimeMillis() + name + " closed - exiting"); } catch (Exception e) { System.out.println ("Error in thread: " + name ); e.printStackTrace(); } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070308/d9a163c5/attachment-0084.html From eu259473 at tele2.it Fri Mar 9 02:46:20 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 09 Mar 2007 10:46:20 +0100 Subject: [Rxtx] rxtx: tru64 unix make fails Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070309/3b654523/attachment-0084.html From lyon at docjava.com Fri Mar 9 03:58:32 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 Mar 2007 05:58:32 -0500 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi All, The deadlock issue is one that I have been thinking about for some time now. It seems to me that we need a resource manager that enables assignment to a known process. The one thing that seems important about serial ports is that two applications should not use the same serial port at the same time. When this happens, it throws an exception. OK. The exception is a response to a lock condition that arises from an unavailable resource. An abstract implementation (not born of native methods) might assign a serial port to an application, until the application releases it (or is forced to release it by some kill mechanism). Some resources (like a registry) can be reused. But others, like the serial port, cannot. In the case of the serial port, we would like, I think, to have the flyweight design pattern without sharing and with object assignment tracking. A means of breaking deadlock (like a leasing mechanism) seems very useful, to me. My guess is that we can serialize the state of the Parametric Singleton Pattern (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) into the Preferences of the System. Preferences.systemRoot() might help with that. When a resource is checked out, the lease time and owner are listed. A thread that does this can be killed, but applications outside of Java are problematic. There is a compelling problem here. It is not just serial ports. Sound cards, cameras, microphones, files, tape drives, etc. All are consumed resources that are assigned to an application (or user) and deprive other applications, or users, from use. What, if anything, should we do? At present we throw PortInUseExceptions. Is that it? Can we do better? OK, the port is in use. Now what? Do I have to be root to go remove lock files and kill applications? Is there a better way? Thanks! - Doug >I've just struck an issue using rxtx in a multi-threaded environment: > >If I have 3 threads trying to open *the same* >comm-port I get a deadlock in >CommPortIdentifier.open >If I have just 2, it works fine - I get a >PortInUseException which is nice and I can >handle it. > >The 3 thread->deadlock thing is causing me issues. >(Sample code below). > >This is from the java thread-dump > >Found one Java-level deadlock: >============================= >"Thread-2": > waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), > which is held by "Thread-1" >"Thread-1": > waiting to lock monitor 0x0003e9cc (object >0x2450e108, a gnu.io.CommPortIdentifier ), > which is held by "Thread-2" > >Java stack information for the threads listed above: >=================================================== >"Thread-2": > at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) > - waiting to lock <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) >"Thread-1": > at java.lang.Object.wait(Native Method) > - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) > - locked <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) > > >(Apart from this, rxtx is working fantastically for us). > >I'm thinking I'll have to implement some sort of >locking mechanism that *doesn't* use java >synchronization to prevent this situation. >(Which doesn't sound like a good idea to me). > >Any ideas? > >Thanks, > >Greg Hanna > >============= RXTXLockTest.java ======================================== > >import gnu.io.CommPort; >import gnu.io.CommPortIdentifier; > >/** > * @author Greg Hanna > * Minimal code to create a deadlock with rxtx in multithreaded open > */ >public class RXTXLockTest { > ? > ?public static void main(String[] args) { > ?try { > ?CommPortIdentifier cpiCom1 = >CommPortIdentifier.getPortIdentifier ("COM14"); > ?OpenThread t1 = new OpenThread (" one ", cpiCom1); > ?OpenThread t2 = new OpenThread (" two ", cpiCom1); > ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); > ?t1.start(); > ?t2.start(); > ?t3.start(); // comment this out >and it runs with (expected) PortInUseException > ?} catch (Exception e) { > ?e.printStackTrace(); > ?} > ?} >} > >class OpenThread extends Thread { > ?String name; > ?CommPortIdentifier cpi; > ?CommPort cp; > ?public OpenThread (String name, CommPortIdentifier cpi) { > ? this.name = name; > ?this.cpi = cpi; > ?System.out.println >(System.currentTimeMillis() + name + " thread >created"); > ?} > ?public void run () { > ?try { > ?System.out.println >(System.currentTimeMillis() + name + " opening"); > ?cp = cpi.open(name, 2000); > ?System.out.println >(System.currentTimeMillis() + name + " opened - >sleeping"); > ?sleep (2000); // do the serial comms with the device. > ?System.out.println >(System.currentTimeMillis() + name + " slept - >closing"); > ?cp.close(); > ?System.out.println >(System.currentTimeMillis() + name + " closed - >exiting"); > ?} catch (Exception e) { > System.out.println ("Error in thread: " + name ); > ?e.printStackTrace(); > ?} > ?} >} > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Mar 9 06:37:45 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 Mar 2007 06:37:45 -0700 (MST) Subject: [Rxtx] rxtx: tru64 unix make fails In-Reply-To: References: Message-ID: On Fri, 9 Mar 2007, "Giuseppe Marchese" wrote: > Sorry for delay. > ? > This is log for ./configure and make > error. > ? > thanks for attention > ? > Make: '%.java,$(TOP)/$(CLASSDEST)/%.class,$(wildcard $(SPATH)/*.java)': extra chars.? > Stop. > Hi Giuseppe You need to use GNU make with the Makefile. I suspect the tru64 make is not happy with those rules. > configure: exit 0 Looks like configure is fairly happy. From tjarvi at qbang.org Sat Mar 10 07:43:51 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 07:43:51 -0700 (MST) Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi Doug I have very little time to look into this further but what we could do is open up an rxtx 3 devel branch in which a proof of concept could be worked on. It could be the proof of concept for a JSR others including Sun could look at/work on or parts of it could be recycled in a JSR. I'm working very hard on rxtx right now but it does not show. I'm looking at win64, mac intel/ppc, usb bluetooth and usb serial dongles. Some are going to be more tested than others but they are all on the plate. I'll be pushing all the fixes upstream when they are done. So I'm very busy in 2.1 but we could open a new branch. On Fri, 9 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > The deadlock issue is one that I have been thinking about > for some time now. > It seems to me that we need a resource manager that enables assignment > to a known process. > > The one thing that seems important about serial > ports is that two applications should not use the > same serial port at the same time. When this > happens, it throws an exception. > OK. > > The exception is a response to a lock condition that > arises from an unavailable resource. > > An abstract implementation (not born of native methods) might > assign a serial port to an application, until the > application releases it (or is forced to release > it by some kill mechanism). > > Some resources (like a registry) can be reused. > But others, like the serial port, > cannot. > > In the case of the serial port, we would like, I think, to > have the flyweight design pattern > without sharing and with object assignment tracking. > A means of breaking deadlock (like a leasing > mechanism) seems very useful, to me. > > My guess is that we can serialize the state of the Parametric Singleton Pattern > (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) > into the Preferences of the System. Preferences.systemRoot() might help > with that. When a resource is checked out, the lease time and owner are > listed. A thread that does this can be killed, but applications outside of Java > are problematic. > > There is a compelling problem here. It is not just serial ports. > Sound cards, cameras, microphones, files, tape drives, etc. All are consumed > resources that are assigned to an application (or > user) and deprive other applications, > or users, from use. > > What, if anything, should we do? At present we throw PortInUseExceptions. > Is that it? > Can we do better? > OK, the port is in use. Now what? > Do I have to be root to go remove lock files and kill applications? > Is there a better way? > > Thanks! > - Doug > >> I've just struck an issue using rxtx in a multi-threaded environment: >> >> If I have 3 threads trying to open *the same* >> comm-port I get a deadlock in >> CommPortIdentifier.open >> If I have just 2, it works fine - I get a >> PortInUseException which is nice and I can >> handle it. >> >> The 3 thread->deadlock thing is causing me issues. >> (Sample code below). >> >> This is from the java thread-dump >> >> Found one Java-level deadlock: >> ============================= >> "Thread-2": >> waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), >> which is held by "Thread-1" >> "Thread-1": >> waiting to lock monitor 0x0003e9cc (object >> 0x2450e108, a gnu.io.CommPortIdentifier ), >> which is held by "Thread-2" >> >> Java stack information for the threads listed above: >> =================================================== >> "Thread-2": >> at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) >> - waiting to lock <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> "Thread-1": >> at java.lang.Object.wait(Native Method) >> - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) >> - locked <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> >> >> (Apart from this, rxtx is working fantastically for us). >> >> I'm thinking I'll have to implement some sort of >> locking mechanism that *doesn't* use java >> synchronization to prevent this situation. >> (Which doesn't sound like a good idea to me). >> >> Any ideas? >> >> Thanks, >> >> Greg Hanna >> >> ============= RXTXLockTest.java ======================================== >> >> import gnu.io.CommPort; >> import gnu.io.CommPortIdentifier; >> >> /** >> * @author Greg Hanna >> * Minimal code to create a deadlock with rxtx in multithreaded open >> */ >> public class RXTXLockTest { >> ? >> ?public static void main(String[] args) { >> ?try { >> ?CommPortIdentifier cpiCom1 = >> CommPortIdentifier.getPortIdentifier ("COM14"); >> ?OpenThread t1 = new OpenThread (" one ", cpiCom1); >> ?OpenThread t2 = new OpenThread (" two ", cpiCom1); >> ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); >> ?t1.start(); >> ?t2.start(); >> ?t3.start(); // comment this out >> and it runs with (expected) PortInUseException >> ?} catch (Exception e) { >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> class OpenThread extends Thread { >> ?String name; >> ?CommPortIdentifier cpi; >> ?CommPort cp; >> ?public OpenThread (String name, CommPortIdentifier cpi) { >> ? this.name = name; >> ?this.cpi = cpi; >> ?System.out.println >> (System.currentTimeMillis() + name + " thread >> created"); >> ?} >> ?public void run () { >> ?try { >> ?System.out.println >> (System.currentTimeMillis() + name + " opening"); >> ?cp = cpi.open(name, 2000); >> ?System.out.println >> (System.currentTimeMillis() + name + " opened - >> sleeping"); >> ?sleep (2000); // do the serial comms with the device. >> ?System.out.println >> (System.currentTimeMillis() + name + " slept - >> closing"); >> ?cp.close(); >> ?System.out.println >> (System.currentTimeMillis() + name + " closed - >> exiting"); >> ?} catch (Exception e) { >> System.out.println ("Error in thread: " + name ); >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 mm at UDel.Edu Sat Mar 10 14:48:32 2007 From: mm at UDel.Edu (Mike Markowski) Date: Sat, 10 Mar 2007 16:48:32 -0500 Subject: [Rxtx] rxtx and Sun's comm api Message-ID: <45F327B0.2060004@udel.edu> Hi all, I joined the list a few days ago and apologize for what is likely a frequently asked question, though I haven't yet found it anywhere. I learned about rxtx.org through the readme on Sun's version 2 of their comms api. They give recommendations in that readme regarding how a better comms api should be written. Is this the aim of rxtx.org? I wrote an app on my linux box using the Sun comms api (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the fact that only linux and Solaris are supported. So I'm glad to find rxtx.org and am just reading up on how make the conversion so Windows users will be able to run the program as well. At the same time I'm just curious if rxtx.org and Sun are both heading in the same direction. Thanks for any background or historical info. Feel free to point me to any www pages if my googling has just completely missed the target! Thanks again, Mike From tjarvi at qbang.org Sat Mar 10 15:35:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 15:35:25 -0700 (MST) Subject: [Rxtx] rxtx and Sun's comm api In-Reply-To: <45F327B0.2060004@udel.edu> References: <45F327B0.2060004@udel.edu> Message-ID: On Sat, 10 Mar 2007, Mike Markowski wrote: > Hi all, > > I joined the list a few days ago and apologize for what is likely a > frequently asked question, though I haven't yet found it anywhere. I > learned about rxtx.org through the readme on Sun's version 2 of their > comms api. They give recommendations in that readme regarding how a > better comms api should be written. Is this the aim of rxtx.org? > > I wrote an app on my linux box using the Sun comms api > (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the > fact that only linux and Solaris are supported. So I'm glad to find > rxtx.org and am just reading up on how make the conversion so Windows > users will be able to run the program as well. At the same time I'm > just curious if rxtx.org and Sun are both heading in the same direction. > > Thanks for any background or historical info. Feel free to point me to > any www pages if my googling has just completely missed the target! > I do not have any news (good or bad) concerning RXTX and Sun working together but perhaps others here do. The main goal of RXTX is to expose POSIX termios interfaces to java users. The future support of javax.comm is questionable. We do not have resources for everything. gnu.io (RXTX 2.1) will be supported going forward and functions the same as CommAPI 2.0. If you have control of the source code you are working with, I would not advise using CommAPI 2.0 javax.comm. We do support CommAPI 2.0 javax.comm for older applications but I do not think that will last much longer for practical reasons. The download interest in CommAPI 2.0 javax.comm support is becomming negligible on this end. There has been discussion of a JSR effort but I do not know of any status change since it was mentioned. One problem with a JSR is that even a light weight process is going to be difficult for RXTX at this time. Maybe that will change in the future but then again it may not. For now, we are just going forward 'as is' in rxtx 2.1 with package gnu.io while trying as a secondary effort to backport the changes to rxtx 2.0 for javax.comm support for users that do not have a choice. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Mar 11 07:19:40 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 11 Mar 2007 08:19:40 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: Hi All, I have been a proponent of a JSR that makes use of RXTX. I have executed the proper agreements with Sun. At this point we are in the: Early Draft Review of Draft Specifications Stage. The best thing to do is to enter the quiet period and create a specification. The question of exactly how we, as a group, want to approach this problem, remains open. Typically, we should have both a specification and a reference implementation. Thus, it would be to our best advantage to have a nice, stable, cross platform RXTX distro that adheres to the groups specification. Now, from a specification standpoint, my personal view on the matter is that we create a series of interfaces, with nice documentation (or at least javadoc). Is this a good idea? Should we have a pure interface specification for the communication API? There are several issues, in my mind, which still weigh on us. Hot-pluggable dongles, long discovery process on pop-up ports, lack of uniformity on device names, lack of uniformity on locking, a precise understanding of how the SerialPortResourceManager works (or even if we should have one). The more questions we answer in our reference implementation, the better our specification will get. RXTX is a good working prototype, but, I don't know if that is what we want to use for a specification. Here is what I have for a CommPortInterface: */ public interface CommPortInterface { /** * @return a string representation of this port. */ String toString(); /** * Gets the name of the communications port. This name should correspond to * something the user can identify, like the label on the hardware. * @return name of the port */ String getName(); /** * @return an input stream that can be used to read data from the * communications port. If the port doesn't support reading data, this * method returns null. *

* The blocking behaviour of this input stream depends on the threshold * and timeout values, as shown below for a read buffer size of n * bytes: * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ThresholdTimeoutBlocking behaviour
StateValueStateValue
disableddisabledblock until data is available
enabledm bytesdisabledblock until min(m, n) bytes are available
disabledenabledt msblock for t ms or until data is available
enabledm bytesenabledt msblock for t ms or until min(m, n) bytes are * available
* @throws java.io.IOException */ InputStream getInputStream() throws IOException; /** * @return an output stream that can be used to send data to the * communications port. If the port doesn't support sending data, this * method returns null. * @throws java.io.IOException */ OutputStream getOutputStream() throws IOException; /** * Closes this communications port. * All PortOwnershipListeners will be? * notified of this change of ownership. Further method calls on this? * object will throw IllegalStateException. Further calls on the? * associated InputStream or OutputStream will throw IOException. *

* Close does not block. Undelivered data is discarded. Blocked read and? * write operations are aborted if the underlying operating systems? * supports an IO abort mechanism. To await the delivery of undelivered? * data call OutputStream.flush() or OutputStream.close() before calling? * Port.close(). */ void close(); /** * Enables receive threshold. * When the specified threshold number of bytes are retrieved, read will * return immediately. * * @param thresh the number of bytes in the input buffer * @throws gnu.io.UnsupportedCommOperationException * if receive threshold is * not supported by the driver * @see #disableReceiveThreshold */ void enableReceiveThreshold(int thresh) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive threshold. * * @see #enableReceiveThreshold */ void disableReceiveThreshold(); /** * @return true if receive threshold is enabled. * * @see #enableReceiveThreshold */ boolean isReceiveThresholdEnabled(); /** * @return the receive threshold value. If receive threshold is diabled * or not supported, this value is meaningless. * * @see #enableReceiveThreshold */ int getReceiveThreshold(); /** * Enables receive timeout. * When the specified number of milliseconds have elapsed, read will * return immediately. * * @param rcvTimeout the number of milliseconds to block for * @throws gnu.io.UnsupportedCommOperationException * if receive timeout is * not supported by the driver * @see #disableReceiveTimeout */ void enableReceiveTimeout(int rcvTimeout) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive timeout. * * @see #enableReceiveTimeout */ void disableReceiveTimeout(); /** * @return true if receive timeout is enabled. * * @see #enableReceiveTimeout */ boolean isReceiveTimeoutEnabled(); /** * @return the receive timeout value. If receive timeout is diabled * or not supported, this value is meaningless. * * @see #enableReceiveTimeout */ int getReceiveTimeout(); /** * Enables receive framing. * The supplied byte value in the input suggests the end of the received * frame, and read returns immediately. Only the low 8 bits of the * supplied value are significant. * * @param framingByte the frame delimiter * @throws gnu.io.UnsupportedCommOperationException * if receive framing is * not supported by the driver * @see #disableReceiveFraming */ void enableReceiveFraming(int framingByte) throws UnsupportedCommOperationException; /** * Disables receive framing. * * @see #enableReceiveFraming */ void disableReceiveFraming(); /** * @return true if receive framing is enabled. * * @see #enableReceiveFraming */ boolean isReceiveFramingEnabled(); /** * @return true if receive framing byte. If receive framing is diabled * or not supported, this value is meaningless. * * @see #enableReceiveFraming */ int getReceiveFramingByte(); /** * Sets the input buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setInputBufferSize(int size); /** * @return the input buffer size. * The driver may choose not to report correct values. */ int getInputBufferSize(); /** * Sets the output buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setOutputBufferSize(int size); /** * @return the output buffer size. * The driver may choose not to report correct values. */ int getOutputBufferSize(); } What do you think of that? Note the wishy washy nature of the spec: The driver may choose to ignore this method. Is that good enough for us? Thanks! - Doug From ra85551 at gmail.com Sun Mar 11 08:44:45 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Sun, 11 Mar 2007 17:44:45 +0300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hello, world! I am writing application that communicates with modem via AT commands. My OS is Linux Kubuntu Feisty Herd, to ensure that my application will run properly under Windows XP I installed VMWare server. When I tried to send AT command and evaluate modem answer under WinXP @ VMWare server, I actually didn't receive anything. I think that VM settings are right, because I do can communicate with modem by using standard HyperTerminall as well as I can do on native Windows. So, why RXTX doesn't work under VM, but works under Linux and pure Windows XP (i tested it there) well? The send/receive method code follows. private String sendATCommand(String command, final String waitFor, final boolean isRegex, boolean isAddCRLF, long timeout) throws BeaconConnectException { final long POLL_PERIOD = 100; final int BUFFER_SIZE = 512; final byte[] buffer = new byte[BUFFER_SIZE]; final InputStream serialInput; final OutputStream serialOutput; try { serialInput = serialPort.getInputStream(); if (command != null) { serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } } catch (IOException e) { throw new MyException("serial I/O error"); } TimerTask task = new TimerTask() { int offset = 0; int bytesRead; public synchronized void run() { try { if (serialInput.available() > 0) { bytesRead = serialInput.read(buffer, offset, BUFFER_SIZE - offset); } else { return; } } catch (IOException e) { // do nothing - maybe next time we'll read something } offset += bytesRead; if (waitFor != null) { String temporary = new String(buffer, 0, offset).trim(); if (isRegex && temporary.matches(waitFor) || temporary.contains(waitFor)) { cancel(); notify(); } } } }; Timer timer = new Timer(); timer.schedule(task, POLL_PERIOD, POLL_PERIOD); synchronized (task) { try { task.wait(timeout); task.cancel(); } catch (InterruptedException e) { } } //Cut off leading and trailing CRs, LFs and zeroes String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); System.out.println(response); return response; } -- Pavel Parkhomenko From tjarvi at qbang.org Sun Mar 11 11:48:22 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:48:22 -0600 (MDT) Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: On Sun, 11 Mar 2007, Pavel Parkhomenko wrote: > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. > > private String sendATCommand(String command, final String waitFor, > final boolean isRegex, boolean isAddCRLF, long timeout) > throws BeaconConnectException > { > final long POLL_PERIOD = 100; > final int BUFFER_SIZE = 512; > final byte[] buffer = new byte[BUFFER_SIZE]; > final InputStream serialInput; > final OutputStream serialOutput; > try > { > serialInput = serialPort.getInputStream(); > if (command != null) > { > serialOutput = serialPort.getOutputStream(); > if (isAddCRLF) > { > command += "\r\n"; > } > System.out.println(command); > serialOutput.write(command.getBytes()); > } > } > catch (IOException e) > { > throw new MyException("serial I/O error"); > } > > TimerTask task = new TimerTask() > { > int offset = 0; > int bytesRead; > public synchronized void run() > { > try > { > if (serialInput.available() > 0) > { > bytesRead = serialInput.read(buffer, offset, > BUFFER_SIZE - offset); > } > else > { > return; > } > } > catch (IOException e) > { > // do nothing - maybe next time we'll read something > } > offset += bytesRead; > if (waitFor != null) > { > String temporary = new String(buffer, 0, offset).trim(); > if (isRegex && temporary.matches(waitFor) || > temporary.contains(waitFor)) > { > cancel(); > notify(); > } > } > } > }; > > Timer timer = new Timer(); > timer.schedule(task, POLL_PERIOD, POLL_PERIOD); > synchronized (task) { > try > { > task.wait(timeout); > task.cancel(); > } > catch (InterruptedException e) > { > } > } > //Cut off leading and trailing CRs, LFs and zeroes > String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); > System.out.println(response); > return response; > } > > > Hi Pavel VMWare should not be a problem. I've used it in the past - though not with a modem. Make sure nothing else is using the modem. Then look in the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an example that should work. Note that modems could care less what OS is on top. If you are trying to match new lines to the OS and sending it to the mode for AT commands, thats probably a mistake. Also it would not hurt to print out the individual bytes that you are sending to make sure they did not get mangled along the path. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 11:55:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:55:48 -0600 (MDT) Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: On Sun, 11 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > I have been a proponent of a JSR that makes > use of RXTX. I have executed the proper agreements with Sun. > > At this point we are in the: > Early Draft Review of Draft Specifications Stage. > > The best thing to do is to enter the quiet period and create > a specification. The question of exactly how we, as a group, > want to approach this problem, remains open. > > Typically, we should have both a specification and a reference > implementation. Thus, it would be to our best advantage to have > a nice, stable, cross platform RXTX distro that adheres to the > groups specification. > > Now, from a specification standpoint, my personal view on the matter is > that we create a series of interfaces, with nice documentation (or at least > javadoc). > > Is this a good idea? Should we have a pure interface specification for > the communication API? > > There are several issues, in my mind, which still weigh on us. > Hot-pluggable dongles, long discovery process on pop-up ports, > lack of uniformity on device names, lack of uniformity on locking, > a precise understanding of how the SerialPortResourceManager > works (or even if we should have one). > > The more questions we answer in our reference implementation, the > better our specification will get. RXTX is a good working prototype, > but, I don't know if that is what we want to use for a specification. > > Here is what I have for a CommPortInterface: > */ > public interface CommPortInterface { Hi Doug, I can start going through the method interfaces later this week and giving feedback. I would suggest that the JSR should not be too generic in nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel drivers that intend to look like EIA232 ports at the kernel driver level. some ideas: EIA232PortInterface TermiosInterface SerialPortInterface Something that differentiates this from thing like USB, I2C, ... which should not have to deal with legacy serial claiming to be the comm api. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 12:52:19 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 12:52:19 -0600 (MDT) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: No news is good news with these posts. I'll start the process of pinging legal a week from Monday on my end if nobody has objections to the proposal. I just want to make sure everyone has time to raise objections. Obviously, anyone can fork from a previous version if they don't like the new license. I suspect we can avoid that though. On Sun, 4 Mar 2007, Trent Jarvi wrote: > > For those that are wondering what is going on here, this > next bit is the meat of the changes. We agreed a long time > ago to put this disclaimer in. We did a so so job. It was > in rxtx 2.0, not well written, ... So some groups using > rxtx that would like to ship rxtx so users don't need to > download, install, go to the mail-list to find why it failed, > ... Then their legal teams tell them section 5 paragraph 2 > is a show stopper. > > That was never the intent. > > > Now going through what remains... > >> and might need a (TM) suffix to make Sun happy. > > Added disclaimer at the ended 'all trademarks belong...' > >> * Line #15ff - static vs. dynamic linking - you did >> not transcribe the text from the "controlled >> interface exception" when writing this text - and >> this was good so, because these terms originally >> refer to the GPL rather than the LGPL. I think though, >> that these 4 lines are the most important ones and >> should thus be really really clear. I hope that I >> meet your original intent with the following >> suggestions: >> 1.) Instead of "A program.." it would be better to >> say "An exectuable.." in order to be closer to >> the LGPL text. > > OK. As you can see I was trying to adjust GNU text there > for the LGPL. > >> 2.) It would be better to say .. "by being dynamically >> linked with it" to clearly indicate that dynamic >> linking is meant. The matter of compilation is >> already covered by the LGPL so mentioning it again >> just leads to confusion. > > used dynamically linked terminology. > >> 3.) It would be better to say .. "is considered a >> work that uses the library in contrast to section >> 5 of the LGPL, so the terms of the LGPL do not >> apply to the resulting executable". > > I tried to address this more upfront with an intent statement. > Let me know if you have problems with it. I also tried to > make it a little more clear what was derived from the GNU > solution by moving the link location closer to GNU's suggestion. > >> >> Note that LGPL section 5 says: ..."is called a >> "work that uses the Library". Such a work, in isolation, >> is not a derivative work of the Library, and therefore >> falls outside the scope of this License." >> The next paragraph of the LGPL is exactly the problematic >> one that I hope is clarified by the exception terms you >> give. >> > > Thats the intent. Here is the combined fixes. Note that only the > material in /*-- --*/ is being touched. The new GPL license is > there but unmodified. > > > ------------------------ begin proposed new license ------------------- > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Lesser General Public > | License as published by the Free Software Foundation; either > | version 2.1 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Lesser General Public License for more details. > | > | An executable that contains no derivative of any portion of RXTX, but > | is designed to work with RXTX by being dynamically linked with it, > | is considered a "work that uses the Library" subject to the terms and > | conditions of the GNU Lesser General Public License. > | > | The following has been added to the RXTX License to remove > | any confusion about linking to RXTX. We want to allow in part what > | section 5, paragraph 2 of the LGPL does not permit in the special > | case of linking over a controlled interface. The intent is to add a > | Java Specification Request or standards body defined interface in the > | future as another exception but one is not currently available. > | > | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface > | > | As a special exception, the copyright holders of RXTX give you > | permission to link RXTX with independent modules that communicate with > | RXTX solely through the Sun Microsytems CommAPI interface version 2, > | regardless of the license terms of these independent modules, and to copy > | and distribute the resulting combined work under terms of your choice, > | provided that every copy of the combined work is accompanied by a complete > | copy of the source code of RXTX (the version of RXTX used to produce the > | combined work), being distributed under the terms of the GNU Lesser General > | Public License plus this exception. An independent module is a > | module which is not derived from or based on RXTX. > | > | Note that people who make modified versions of RXTX are not obligated > | to grant this special exception for their modified versions; it is > | their choice whether to do so. The GNU Lesser General Public License > | gives permission to release a modified version without this exception; this > | exception also makes it possible to release a modified version which > | carries forward this exception. > | > | You should have received a copy of the GNU Lesser General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > | All trademarks belong to their respective owners. > --------------------------------------------------------------------------*/ > > The original GNU Lesser General Public License Follows. > > > GNU LESSER GENERAL PUBLIC LICENSE > Version 2.1, February 1999 > > Copyright (C) 1991, 1999 Free Software Foundation, Inc. > 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > Everyone is permitted to copy and distribute verbatim copies > of this license document, but changing it is not allowed. > > [This is the first released version of the Lesser GPL. It also counts > as the successor of the GNU Library Public License, version 2, hence > the version number 2.1.] > > Preamble > > The licenses for most software are designed to take away your > freedom to share and change it. By contrast, the GNU General Public > Licenses are intended to guarantee your freedom to share and change > free software--to make sure the software is free for all its users. > > This license, the Lesser General Public License, applies to some > specially designated software packages--typically libraries--of the > Free Software Foundation and other authors who decide to use it. You > can use it too, but we suggest you first think carefully about whether > this license or the ordinary General Public License is the better > strategy to use in any particular case, based on the explanations below. > > When we speak of free software, we are referring to freedom of use, > not price. Our General Public Licenses are designed to make sure that > you have the freedom to distribute copies of free software (and charge > for this service if you wish); that you receive source code or can get > it if you want it; that you can change the software and use pieces of > it in new free programs; and that you are informed that you can do > these things. > > To protect your rights, we need to make restrictions that forbid > distributors to deny you these rights or to ask you to surrender these > rights. These restrictions translate to certain responsibilities for > you if you distribute copies of the library or if you modify it. > > For example, if you distribute copies of the library, whether gratis > or for a fee, you must give the recipients all the rights that we gave > you. You must make sure that they, too, receive or can get the source > code. If you link other code with the library, you must provide > complete object files to the recipients, so that they can relink them > with the library after making changes to the library and recompiling > it. And you must show them these terms so they know their rights. > > We protect your rights with a two-step method: (1) we copyright the > library, and (2) we offer you this license, which gives you legal > permission to copy, distribute and/or modify the library. > > To protect each distributor, we want to make it very clear that > there is no warranty for the free library. Also, if the library is > modified by someone else and passed on, the recipients should know > that what they have is not the original version, so that the original > author's reputation will not be affected by problems that might be > introduced by others. > > Finally, software patents pose a constant threat to the existence of > any free program. We wish to make sure that a company cannot > effectively restrict the users of a free program by obtaining a > restrictive license from a patent holder. Therefore, we insist that > any patent license obtained for a version of the library must be > consistent with the full freedom of use specified in this license. > > Most GNU software, including some libraries, is covered by the > ordinary GNU General Public License. This license, the GNU Lesser > General Public License, applies to certain designated libraries, and > is quite different from the ordinary General Public License. We use > this license for certain libraries in order to permit linking those > libraries into non-free programs. > > When a program is linked with a library, whether statically or using > a shared library, the combination of the two is legally speaking a > combined work, a derivative of the original library. The ordinary > General Public License therefore permits such linking only if the > entire combination fits its criteria of freedom. The Lesser General > Public License permits more lax criteria for linking other code with > the library. > > We call this license the "Lesser" General Public License because it > does Less to protect the user's freedom than the ordinary General > Public License. It also provides other free software developers Less > of an advantage over competing non-free programs. These disadvantages > are the reason we use the ordinary General Public License for many > libraries. However, the Lesser license provides advantages in certain > special circumstances. > > For example, on rare occasions, there may be a special need to > encourage the widest possible use of a certain library, so that it becomes > a de-facto standard. To achieve this, non-free programs must be > allowed to use the library. A more frequent case is that a free > library does the same job as widely used non-free libraries. In this > case, there is little to gain by limiting the free library to free > software only, so we use the Lesser General Public License. > > In other cases, permission to use a particular library in non-free > programs enables a greater number of people to use a large body of > free software. For example, permission to use the GNU C Library in > non-free programs enables many more people to use the whole GNU > operating system, as well as its variant, the GNU/Linux operating > system. > > Although the Lesser General Public License is Less protective of the > users' freedom, it does ensure that the user of a program that is > linked with the Library has the freedom and the wherewithal to run > that program using a modified version of the Library. > > The precise terms and conditions for copying, distribution and > modification follow. Pay close attention to the difference between a > "work based on the library" and a "work that uses the library". The > former contains code derived from the library, whereas the latter must > be combined with the library in order to run. > > GNU LESSER GENERAL PUBLIC LICENSE > TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION > > 0. This License Agreement applies to any software library or other > program which contains a notice placed by the copyright holder or > other authorized party saying it may be distributed under the terms of > this Lesser General Public License (also called "this License"). > Each licensee is addressed as "you". > > A "library" means a collection of software functions and/or data > prepared so as to be conveniently linked with application programs > (which use some of those functions and data) to form executables. > > The "Library", below, refers to any such software library or work > which has been distributed under these terms. A "work based on the > Library" means either the Library or any derivative work under > copyright law: that is to say, a work containing the Library or a > portion of it, either verbatim or with modifications and/or translated > straightforwardly into another language. (Hereinafter, translation is > included without limitation in the term "modification".) > > "Source code" for a work means the preferred form of the work for > making modifications to it. For a library, complete source code means > all the source code for all modules it contains, plus any associated > interface definition files, plus the scripts used to control compilation > and installation of the library. > > Activities other than copying, distribution and modification are not > covered by this License; they are outside its scope. The act of > running a program using the Library is not restricted, and output from > such a program is covered only if its contents constitute a work based > on the Library (independent of the use of the Library in a tool for > writing it). Whether that is true depends on what the Library does > and what the program that uses the Library does. > > 1. You may copy and distribute verbatim copies of the Library's > complete source code as you receive it, in any medium, provided that > you conspicuously and appropriately publish on each copy an > appropriate copyright notice and disclaimer of warranty; keep intact > all the notices that refer to this License and to the absence of any > warranty; and distribute a copy of this License along with the > Library. > > You may charge a fee for the physical act of transferring a copy, > and you may at your option offer warranty protection in exchange for a > fee. > > 2. You may modify your copy or copies of the Library or any portion > of it, thus forming a work based on the Library, and copy and > distribute such modifications or work under the terms of Section 1 > above, provided that you also meet all of these conditions: > > a) The modified work must itself be a software library. > > b) You must cause the files modified to carry prominent notices > stating that you changed the files and the date of any change. > > c) You must cause the whole of the work to be licensed at no > charge to all third parties under the terms of this License. > > d) If a facility in the modified Library refers to a function or a > table of data to be supplied by an application program that uses > the facility, other than as an argument passed when the facility > is invoked, then you must make a good faith effort to ensure that, > in the event an application does not supply such function or > table, the facility still operates, and performs whatever part of > its purpose remains meaningful. > > (For example, a function in a library to compute square roots has > a purpose that is entirely well-defined independent of the > application. Therefore, Subsection 2d requires that any > application-supplied function or table used by this function must > be optional: if the application does not supply it, the square > root function must still compute square roots.) > > These requirements apply to the modified work as a whole. If > identifiable sections of that work are not derived from the Library, > and can be reasonably considered independent and separate works in > themselves, then this License, and its terms, do not apply to those > sections when you distribute them as separate works. But when you > distribute the same sections as part of a whole which is a work based > on the Library, the distribution of the whole must be on the terms of > this License, whose permissions for other licensees extend to the > entire whole, and thus to each and every part regardless of who wrote > it. > > Thus, it is not the intent of this section to claim rights or contest > your rights to work written entirely by you; rather, the intent is to > exercise the right to control the distribution of derivative or > collective works based on the Library. > > In addition, mere aggregation of another work not based on the Library > with the Library (or with a work based on the Library) on a volume of > a storage or distribution medium does not bring the other work under > the scope of this License. > > 3. You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. To do > this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version 2, > instead of to this License. (If a newer version than version 2 of the > ordinary GNU General Public License has appeared, then you can specify > that version instead if you wish.) Do not make any other change in > these notices. > > Once this change is made in a given copy, it is irreversible for > that copy, so the ordinary GNU General Public License applies to all > subsequent copies and derivative works made from that copy. > > This option is useful when you wish to copy part of the code of > the Library into a program that is not a library. > > 4. You may copy and distribute the Library (or a portion or > derivative of it, under Section 2) in object code or executable form > under the terms of Sections 1 and 2 above provided that you accompany > it with the complete corresponding machine-readable source code, which > must be distributed under the terms of Sections 1 and 2 above on a > medium customarily used for software interchange. > > If distribution of object code is made by offering access to copy > from a designated place, then offering equivalent access to copy the > source code from the same place satisfies the requirement to > distribute the source code, even though third parties are not > compelled to copy the source along with the object code. > > 5. A program that contains no derivative of any portion of the > Library, but is designed to work with the Library by being compiled or > linked with it, is called a "work that uses the Library". Such a > work, in isolation, is not a derivative work of the Library, and > therefore falls outside the scope of this License. > > However, linking a "work that uses the Library" with the Library > creates an executable that is a derivative of the Library (because it > contains portions of the Library), rather than a "work that uses the > library". The executable is therefore covered by this License. > Section 6 states terms for distribution of such executables. > > When a "work that uses the Library" uses material from a header file > that is part of the Library, the object code for the work may be a > derivative work of the Library even though the source code is not. > Whether this is true is especially significant if the work can be > linked without the Library, or if the work is itself a library. The > threshold for this to be true is not precisely defined by law. > > If such an object file uses only numerical parameters, data > structure layouts and accessors, and small macros and small inline > functions (ten lines or less in length), then the use of the object > file is unrestricted, regardless of whether it is legally a derivative > work. (Executables containing this object code plus portions of the > Library will still fall under Section 6.) > > Otherwise, if the work is a derivative of the Library, you may > distribute the object code for the work under the terms of Section 6. > Any executables containing that work also fall under Section 6, > whether or not they are linked directly with the Library itself. > > 6. As an exception to the Sections above, you may also combine or > link a "work that uses the Library" with the Library to produce a > work containing portions of the Library, and distribute that work > under terms of your choice, provided that the terms permit > modification of the work for the customer's own use and reverse > engineering for debugging such modifications. > > You must give prominent notice with each copy of the work that the > Library is used in it and that the Library and its use are covered by > this License. You must supply a copy of this License. If the work > during execution displays copyright notices, you must include the > copyright notice for the Library among them, as well as a reference > directing the user to the copy of this License. Also, you must do one > of these things: > > a) Accompany the work with the complete corresponding > machine-readable source code for the Library including whatever > changes were used in the work (which must be distributed under > Sections 1 and 2 above); and, if the work is an executable linked > with the Library, with the complete machine-readable "work that > uses the Library", as object code and/or source code, so that the > user can modify the Library and then relink to produce a modified > executable containing the modified Library. (It is understood > that the user who changes the contents of definitions files in the > Library will not necessarily be able to recompile the application > to use the modified definitions.) > > b) Use a suitable shared library mechanism for linking with the > Library. A suitable mechanism is one that (1) uses at run time a > copy of the library already present on the user's computer system, > rather than copying library functions into the executable, and (2) > will operate properly with a modified version of the library, if > the user installs one, as long as the modified version is > interface-compatible with the version that the work was made with. > > c) Accompany the work with a written offer, valid for at > least three years, to give the same user the materials > specified in Subsection 6a, above, for a charge no more > than the cost of performing this distribution. > > d) If distribution of the work is made by offering access to copy > from a designated place, offer equivalent access to copy the above > specified materials from the same place. > > e) Verify that the user has already received a copy of these > materials or that you have already sent this user a copy. > > For an executable, the required form of the "work that uses the > Library" must include any data and utility programs needed for > reproducing the executable from it. However, as a special exception, > the materials to be distributed need not include anything that is > normally distributed (in either source or binary form) with the major > components (compiler, kernel, and so on) of the operating system on > which the executable runs, unless that component itself accompanies > the executable. > > It may happen that this requirement contradicts the license > restrictions of other proprietary libraries that do not normally > accompany the operating system. Such a contradiction means you cannot > use both them and the Library together in an executable that you > distribute. > > 7. You may place library facilities that are a work based on the > Library side-by-side in a single library together with other library > facilities not covered by this License, and distribute such a combined > library, provided that the separate distribution of the work based on > the Library and of the other library facilities is otherwise > permitted, and provided that you do these two things: > > a) Accompany the combined library with a copy of the same work > based on the Library, uncombined with any other library > facilities. This must be distributed under the terms of the > Sections above. > > b) Give prominent notice with the combined library of the fact > that part of it is a work based on the Library, and explaining > where to find the accompanying uncombined form of the same work. > > 8. You may not copy, modify, sublicense, link with, or distribute > the Library except as expressly provided under this License. Any > attempt otherwise to copy, modify, sublicense, link with, or > distribute the Library is void, and will automatically terminate your > rights under this License. However, parties who have received copies, > or rights, from you under this License will not have their licenses > terminated so long as such parties remain in full compliance. > > 9. You are not required to accept this License, since you have not > signed it. However, nothing else grants you permission to modify or > distribute the Library or its derivative works. These actions are > prohibited by law if you do not accept this License. Therefore, by > modifying or distributing the Library (or any work based on the > Library), you indicate your acceptance of this License to do so, and > all its terms and conditions for copying, distributing or modifying > the Library or works based on it. > > 10. Each time you redistribute the Library (or any work based on the > Library), the recipient automatically receives a license from the > original licensor to copy, distribute, link with or modify the Library > subject to these terms and conditions. You may not impose any further > restrictions on the recipients' exercise of the rights granted herein. > You are not responsible for enforcing compliance by third parties with > this License. > > 11. If, as a consequence of a court judgment or allegation of patent > infringement or for any other reason (not limited to patent issues), > conditions are imposed on you (whether by court order, agreement or > otherwise) that contradict the conditions of this License, they do not > excuse you from the conditions of this License. If you cannot > distribute so as to satisfy simultaneously your obligations under this > License and any other pertinent obligations, then as a consequence you > may not distribute the Library at all. For example, if a patent > license would not permit royalty-free redistribution of the Library by > all those who receive copies directly or indirectly through you, then > the only way you could satisfy both it and this License would be to > refrain entirely from distribution of the Library. > > If any portion of this section is held invalid or unenforceable under any > particular circumstance, the balance of the section is intended to apply, > and the section as a whole is intended to apply in other circumstances. > > It is not the purpose of this section to induce you to infringe any > patents or other property right claims or to contest validity of any > such claims; this section has the sole purpose of protecting the > integrity of the free software distribution system which is > implemented by public license practices. Many people have made > generous contributions to the wide range of software distributed > through that system in reliance on consistent application of that > system; it is up to the author/donor to decide if he or she is willing > to distribute software through any other system and a licensee cannot > impose that choice. > > This section is intended to make thoroughly clear what is believed to > be a consequence of the rest of this License. > > 12. If the distribution and/or use of the Library is restricted in > certain countries either by patents or by copyrighted interfaces, the > original copyright holder who places the Library under this License may add > an explicit geographical distribution limitation excluding those countries, > so that distribution is permitted only in or among countries not thus > excluded. In such case, this License incorporates the limitation as if > written in the body of this License. > > 13. The Free Software Foundation may publish revised and/or new > versions of the Lesser General Public License from time to time. > Such new versions will be similar in spirit to the present version, > but may differ in detail to address new problems or concerns. > > Each version is given a distinguishing version number. If the Library > specifies a version number of this License which applies to it and > "any later version", you have the option of following the terms and > conditions either of that version or of any later version published by > the Free Software Foundation. If the Library does not specify a > license version number, you may choose any version ever published by > the Free Software Foundation. > > 14. If you wish to incorporate parts of the Library into other free > programs whose distribution conditions are incompatible with these, > write to the author to ask for permission. For software which is > copyrighted by the Free Software Foundation, write to the Free > Software Foundation; we sometimes make exceptions for this. Our > decision will be guided by the two goals of preserving the free status > of all derivatives of our free software and of promoting the sharing > and reuse of software generally. > > NO WARRANTY > > 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO > WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. > EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR > OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY > KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE > IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE > LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME > THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. > > 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN > WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY > AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU > FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR > CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE > LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING > RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A > FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF > SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH > DAMAGES. > > END OF TERMS AND CONDITIONS > > How to Apply These Terms to Your New Libraries > > If you develop a new library, and you want it to be of the greatest > possible use to the public, we recommend making it free software that > everyone can redistribute and change. You can do so by permitting > redistribution under these terms (or, alternatively, under the terms of the > ordinary General Public License). > > To apply these terms, attach the following notices to the library. It is > safest to attach them to the start of each source file to most effectively > convey the exclusion of warranty; and each file should have at least the > "copyright" line and a pointer to where the full notice is found. > > > Copyright (C) > > This library is free software; you can redistribute it and/or > modify it under the terms of the GNU Lesser General Public > License as published by the Free Software Foundation; either > version 2.1 of the License, or (at your option) any later version. > > This library is distributed in the hope that it will be useful, > but WITHOUT ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > Lesser General Public License for more details. > > You should have received a copy of the GNU Lesser General Public > License along with this library; if not, write to the Free Software > Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > > Also add information on how to contact you by electronic and paper mail. > > You should also get your employer (if you work as a programmer) or your > school, if any, to sign a "copyright disclaimer" for the library, if > necessary. Here is a sample; alter the names: > > Yoyodyne, Inc., hereby disclaims all copyright interest in the > library `Frob' (a library for tweaking knobs) written by James Random Hacker. > > , 1 April 1990 > Ty Coon, President of Vice > > That's all there is to it! > ------------------------ end of proposed license ------------------ > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From gjhanna at gmail.com Sun Mar 11 14:21:17 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Mon, 12 Mar 2007 09:21:17 +1300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hi Pavel, We are using RXTX under VMWare server in production, quite satisfactorily. We're using Red Hat Enterprise Server 4, and ... Whatever the "enterprise" VMWare product is. Regards, Greg H > Subject: [Rxtx] RXTX under VMWare server > To: rxtx at qbang.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. [ ... snip ... ] -- Pavel Parkhomenko -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070311/4cebb6f9/attachment-0081.html From gergg at cox.net Sun Mar 11 23:39:19 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 12 Mar 2007 00:39:19 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: <45F4E787.6050502@cox.net> Trent Jarvi wrote: > I can start going through the method interfaces later this week and giving > feedback. I would suggest that the JSR should not be too generic in > nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel > drivers that intend to look like EIA232 ports at the kernel driver level. > > some ideas: > > EIA232PortInterface > TermiosInterface > SerialPortInterface > > Something that differentiates this from thing like USB, I2C, ... which > should not have to deal with legacy serial claiming to be the comm api. I'm going to throw out a suggestion, which I am mostly serious about. What would happen if we took the appropriate bits of the J2ME connector API, and just used that as the new COMM API so that finally JSE and JME had a common foundation for these kinds of things? Gregg Wonderly From ra85551 at gmail.com Mon Mar 12 09:08:37 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Mon, 12 Mar 2007 18:08:37 +0300 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Should any application use the modem, HyperTerminal won't be able to talk to the modem. But it actually can send and receive AT comands, while my application cannot :-( > Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Thansk for the reference. I examined that example and found that there's no significant differences between my read/write implementation and that one, except that SimpleSnuV1 listens for serialEvent's, but not for sake of data retrieval, just for printing them out - I don't know why ;-) > Note that modems could care less what OS is on top. If you are trying to > match new lines to the OS and sending it to the mode for AT commands, > thats probably a mistake. I do send strings to serial port, not to OS, and do try to get answers back. If it is the mistake, what's the right way? > Also it would not hurt to print out the > individual bytes that you are sending to make sure they did not get > mangled along the path. Yeah, I am printing these bytes before doing write, but it means that I only see what I intend to write. How can I ensure that these bytes have gone out of the box and reached my modem? BTW, I found that my send/receive method is complex enough, so I've rewritten it. Please, see the following code and point any mistakes, because I don't know where can they remain yet. private static final int LARGE_TIMEOUT = 15000; private static final int SMALL_TIMEOUT = 500; ... private String sendATCommand(String command, String waitFor, boolean isRegex, boolean isAddCRLF) throws BeaconConnectException { byte[] buffer = new byte[512]; int offset; String result = ""; try { if (waitFor != null) { serialPort.enableReceiveTimeout(LARGE_TIMEOUT); } else { serialPort.enableReceiveTimeout(SMALL_TIMEOUT); } if (command != null) { OutputStream serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } offset = 0; InputStream serialInput = serialPort.getInputStream(); while (serialInput.available() != -1) { int bytesRead = serialInput.read(buffer, offset, buffer.length - offset); if (bytesRead == 0) { break; } offset += bytesRead; result = new String(buffer, 0, offset).trim(); if (waitFor != null) { System.out.println(result); if (isRegex && result.matches(waitFor) || result.contains(waitFor)) { break; } } } } catch (UnsupportedCommOperationException e) { throw new MyException("unsupported operation"); } catch (IOException e) { throw new MytException("serial I/O error"); } return result; } -- Pavel Parkhomenko From clayno at hotpop.com Thu Mar 15 02:47:34 2007 From: clayno at hotpop.com (Christopher Layno) Date: Thu, 15 Mar 2007 16:47:34 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi, we're using the latest release of rxtx (2.1-7r2) for our system that has two applications using the library. one application sends requests to the modem while the other simply checks the modem status. we deployed our system on a pentium machine with red hat linux 9.0 installed. now the problem arises when these two applications try to access the same modem at the same time. one of them will eventually have to throw the PortInUseException as shown below: 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException gnu.io.PortInUseException: root PID = 743 Program = java root PID = 743 Program = java root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) this was expected. what we didn't expect though was that if we repeat the scenario 5 times, always 5 times, the application would also throw a VM error: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4473CD21 Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so Current Java thread: at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) - locked <0x44cfd4c8> (a gnu.io.CommPortIdentifier) at ************ at ************ - locked <0x4476a468> (a **********) at ************ at ************ at ************ at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java :261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages( TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run( TCPTransport.java:701) at java.lang.Thread.run(Thread.java:534) note: i replaced some sensitive data with asterisks our team has looked everywhere on the internet, including your mail archives, for a solution to this problem but to no avail. i really hope you could help us out on this one. thanks in advance! best regards, chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070315/1936460a/attachment-0078.html From tjarvi at qbang.org Fri Mar 16 04:30:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 04:30:25 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: On Thu, 15 Mar 2007, Christopher Layno wrote: > hi, > > we're using the latest release of rxtx (2.1-7r2) for our system that has two > applications using the library. one application sends requests to the modem > while the other simply checks the modem status. we deployed our system on a > pentium machine with red hat linux 9.0 installed. > > now the problem arises when these two applications try to access the same > modem at the same time. one of them will eventually have to throw the > PortInUseException as shown below: > > 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException > gnu.io.PortInUseException: root PID = 743 Program = java root PID = > 743 Program = java root PID = 743 Program = ??? root PID = 743 Program > = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root > PID = 743 Program = ??? root PID = 743 Program = ??? > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > > this was expected. what we didn't expect though was that if we repeat the > scenario 5 times, always 5 times, the application would also throw a VM > error: > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x4473CD21 > Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 > Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so > > Current Java thread: > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) Hi Chris The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. The code is originally by Werner Almesberger. He gave us permission to use it in rxtx. You might look at what has changed since 1998 in his fuser application. Or you can just do like other OSs and do the following in fuserImp.c JNIEXPORT jstring JNICALL Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv *env, jobject obj, jstring arg) { return (*env)->NewStringUTF(env, "Unknown Application"); } It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. -- Trent Jarvi tjarvi at qang.org From Adrien.TOS at ingenico.com Fri Mar 16 05:11:12 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Fri, 16 Mar 2007 12:11:12 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903CBC312@frsnprexc1.usr.ingenico.loc> Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070316/972ab214/attachment-0077.html From joachim at buechse.de Fri Mar 16 05:13:24 2007 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 16 Mar 2007 12:13:24 +0100 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. From tjarvi at qbang.org Fri Mar 16 16:36:29 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 16:36:29 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Fri Mar 16 16:02:23 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 16 Mar 2007 18:02:23 -0400 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Not all platforms are Unix based. Also mixing native library usage and command-line calls is not an elegant solution, IMHO. One or the other, but not both. Andre On 16-Mar-07, at 07:13 , Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is > trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We >> only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From clayno at hotpop.com Sun Mar 18 22:17:28 2007 From: clayno at hotpop.com (Christopher Layno) Date: Mon, 19 Mar 2007 12:17:28 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi everyone, thank you so much for your replies. they were really helpful. anyway, before i sent the email, my team was already implementing a temporary solution by using joachim's suggestion. we invoked a lsof command from our java code although i share the same concern with trent and andre-john about portability issues. that's why i said it's just temporary. my superiors have yet to approve our bug fix. so my question now is this: is recompiling the rxtx source code the only way to solve this problem? because if it's the only solution, then i think my superiors would rather have a new release from the rxtx community itself that fixes this bug(?) rather than have my team recompile the source code. best regards, chris Trent Jarvi wrote: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. ... It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070318/237463b2/attachment-0074.html From tjarvi at qbang.org Mon Mar 19 16:20:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Mar 2007 16:20:52 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: Hi Chris I can compile a new version after the 21st if you do not feel comfortable doing so. Please send me an email reminder off-line then. On Mon, 19 Mar 2007, Christopher Layno wrote: > hi everyone, > > thank you so much for your replies. they were really helpful. > > anyway, before i sent the email, my team was already implementing a > temporary solution by using joachim's suggestion. > we invoked a lsof command from our java code although i share the same > concern with trent and andre-john about > portability issues. that's why i said it's just temporary. my superiors have > yet to approve our bug fix. > > so my question now is this: is recompiling the rxtx source code the only way > to solve this problem? because if it's the only > solution, then i think my superiors would rather have a new release from the > rxtx community itself that fixes this bug(?) > rather than have my team recompile the source code. > > best regards, > > chris > > Trent Jarvi wrote: > > Hi Joachim > > It would be nice to have that functionality but calling the program > introduces too many issues imho. Explaining to someone why rxtx invoked a > rogue lsof does not sound very interesting. > > On Fri, 16 Mar 2007, Joachim Buechse wrote: > > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: > > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. > > _______________________________________________ > Rxtx mailing list > Rxtx 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 Eric.Arseneau at sun.com Tue Mar 20 11:47:33 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Tue, 20 Mar 2007 10:47:33 -0700 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 Message-ID: <46001E35.9040608@sun.com> Anyone have any experience with RXTX working with JDK 6 on other platforms ? From mm at UDel.Edu Tue Mar 20 12:18:29 2007 From: mm at UDel.Edu (Mike Markowski) Date: Tue, 20 Mar 2007 14:18:29 -0400 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 In-Reply-To: <46001E35.9040608@sun.com> References: <46001E35.9040608@sun.com> Message-ID: <46002575.4000306@udel.edu> Eric Arseneau wrote: > Anyone have any experience with RXTX working with JDK 6 on other platforms ? I'm using 32 bit intel, gentoo linux, jdk6 with no problems. My applications only use a serial port, though, nothing on the parallel port. Mike From falko.guderian at gmx.de Wed Mar 21 08:17:35 2007 From: falko.guderian at gmx.de (Falko Guderian) Date: Wed, 21 Mar 2007 15:17:35 +0100 Subject: [Rxtx] RXTX binaries for SH4 Message-ID: <46013E7F.40102@gmx.de> Dear developers, I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no possiblities to compile the source code. Better, I'm not able to do this at the moment. Can you provide me with rxtxSerial.dll (SH4) in the rxtx-2.1-8-testing version? (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) The reason for the testing version is I need custom baud rates. Thanks for help. Kind regards, Falko Guderian From tjarvi at qbang.org Wed Mar 21 21:38:37 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Mar 2007 21:38:37 -0600 (MDT) Subject: [Rxtx] RXTX binaries for SH4 In-Reply-To: <46013E7F.40102@gmx.de> References: <46013E7F.40102@gmx.de> Message-ID: On Wed, 21 Mar 2007, Falko Guderian wrote: > Dear developers, > > I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no > possiblities to compile the source code. Better, I'm not able to do this > at the moment. Can you provide me with rxtxSerial.dll (SH4) in the > rxtx-2.1-8-testing version? > (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) > > The reason for the testing version is I need custom baud rates. > > Thanks for help. > Hi Falko WinCE binary format is not supported by gcc. That makes compiling limited to those familiar with the WinCE tools. I hope someone is able to provide them for you but it is not likely. WinCE has been compiled by others in the past but rxtx.org builds have never included WinCE. There is some information with the source concerning WinCE builds if you decide to do it. We can share your results too if you like. The source in the WinCE has never been updated for the custom baud rate. That would need changes from the main source I presume. If you look at the source, you will note that Michal Hobot created a mini fork in the source to handle wince but it has not been updated for 3 years. -- Trent Jarvi tjarvi at qbang.org From Adrien.TOS at ingenico.com Thu Mar 22 07:08:55 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Thu, 22 Mar 2007 14:08:55 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Hi everybody, Do you have any comments on this issue? Thanks! AT ________________________________ De : Adrien TOS Envoy? : vendredi 16 mars 2007 12:11 ? : 'rxtx at qbang.org' Cc : Adrien TOS Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070322/2306c538/attachment-0070.html From jeremy.reeve at zen.co.uk Mon Mar 19 07:36:04 2007 From: jeremy.reeve at zen.co.uk (Jeremy S. Reeve) Date: Mon, 19 Mar 2007 13:36:04 +0000 Subject: [Rxtx] rxtx failing to compile on Fedora Core 6 Message-ID: <1174311364.21865.6.camel@d9thc> When trying to compile latest source : rxtx-2.1-7r2 I get the following when running configure: ---------------- checking os.version 2.6.18-1.2200.fc5smp WARNING: configure is having a hard time determining which directory contains the file jni_md.h. Edit Makefile and fix the variable JAVANATINC to point to the correct directory. The following options are available: /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/ /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/linux/ If there are more than one option available the first was selected. WARNING: Kernel include files do not match the current kernel configure: creating ./config.status ------------------------ which seems OK checking the resultant Makefile but when attempting to build with gmake install I get the following output : ---------------------- 34 problems (34 warnings)/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/javah -classpath .:/home/jsr/rxtxsrc/rxtx-2.1-7r2:/home/jsr/rxtxsrc/rxtx-2.1-7r2/src:/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/ext/RXTXcomm.jar -d i686-pc-linux-gnu -jni `(for i in CommDriver CommPortEnumerator CommPortIdentifier CommPort CommPortOwnershipListener Configure I2C I2CPortEvent I2CPortEventListener I2CPort LPRPort NoSuchPortException ParallelPortEvent ParallelPortEventListener ParallelPort PortInUseException Raw RawPortEvent RawPortEventListener RawPort RS485 RS485PortEvent RS485PortEventListener RS485Port RXTXCommDriver RXTXPort RXTXVersion SerialPortEvent SerialPortEventListener SerialPort UnsupportedCommOperationException UnSupportedLoggerException Zystem;do \ if grep > /dev/null native.* \( /home/jsr/rxtxsrc/rxtx-2.1-7r2/./src/$i.java; then \ echo gnu.io.$i; \ fi; \ done)` i686-pc-linux-gnu/gnu_io_CommPortIdentifier.h: No such file or directory make: *** [/home/jsr/rxtxsrc/rxtx-2.1-7r2/gnu/io/CommDriver.class] Error 1 ------------------------ Any ideas or pointers? Regards, Jeremy From tjarvi at qbang.org Sat Mar 24 08:12:54 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 Mar 2007 08:12:54 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > From Adrien.TOS at ingenico.com Sat Mar 24 11:53:22 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Sat, 24 Mar 2007 18:53:22 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> I do not have the threshold setting enabled, I have explicitely disabled it with: port_.disableReceiveThreshold(); I have also run the same tests with the threshold setting enabled, but they also fail in the same way as described below. So it seems there is a problem with timeout handling on Win32? ________________________________ From: rxtx-bounces at qbang.org on behalf of Trent Jarvi Sent: Sat 3/24/2007 3:12 PM To: RXTX Developers and Users Subject: Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 8312 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20070324/f9e39c9b/attachment-0068.bin From greg.johnson at manchester.ac.uk Sun Mar 25 13:41:36 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Sun, 25 Mar 2007 21:41:36 +0200 Subject: [Rxtx] Mac intel weirdness Message-ID: Hi folks, I'm trying to get rxtx to work on my macbook pro with a USB-serial dongle on it. I am using the 2.1-8 code from the CVS (though it seems to report itself as 2.1-7: makes it difficult to prove to oneself that the changes have 'taken'! - line 4210 in SerialImp.c, line 40 in RXTXVersion.java) I am trying the 2.1-8 because of horrible lock problems in 2.1-7. However, the serialport closure code seems to be broken - it won't close because it believes the (previously opened!) port doesn't exist. Here is what I'm trying: 0. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "false" 1. Open a port Serialport serialport = (SerialPort) commportidentifier.open ("test",100); 2. Talk to a device ... 3. Close port serialport.close(); 4. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "true" - why is this? 5. Try to reopen port Serialport serialport2 = (SerialPort) commportidentifier.open("test", 100); throws PortInUseException. I've dug around a bit in the source, and it seems the SerialPort.close () should call the CommPortIdentifier.internalClosePort() (line 67 of CommPort.java). However, I crash out with the NoSuchPortException when getPortIdentifier is called. Which seems quite weird to me, seeing as it is called on this - which was create just beforehand. Does anyone know how to fix this? Cheers, greg From knute at frazmtn.com Sat Mar 24 10:32:38 2007 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 24 Mar 2007 09:32:38 -0700 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc>, Message-ID: <4604F036.17833.135298@knute.frazmtn.com> > >The behavior of timeout depends upon the setting of the threshold. Do you >have the threshold setting? > This is the same bug I reported last fall. There was a fellow that sent me an email asking if it had been fixed. I told him I didn't think so. He got somebody to write a fix for him but I have not been able to contact him again for the actual changes. The inaccurate timeout and the failure of blocking when no timeouts are set is a serious bug in my humble opinion and renders the software unusable for my applications. I'd really like to have an alternative to the Sun comm api but there just isn't one that I know of. -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Mar 26 16:17:00 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 26 Mar 2007 16:17:00 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> Message-ID: >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. From ra85551 at gmail.com Tue Mar 27 10:18:36 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Tue, 27 Mar 2007 20:18:36 +0400 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Ultimately I found a solution. At first, that wasn't actually the VMWare + WinXP + RXTX issue, that was WinXP + RXTX issue. But on pure XP it sometimes workes, sometimes not, while under VMWare I had never seen my snippet working at all. SimpleSnuV1.java would not help me, because there is only one line I missed, and SimpleSnuV1.java also doesn't contain it! It is as follows: serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_OUT | SerialPort.FLOWCONTROL_RTSCTS_IN); Thank you for your attention. -- Pavel Parkhomenko From griff at op.pl Wed Mar 28 01:28:19 2007 From: griff at op.pl (griff@op.pl) Date: Wed, 28 Mar 2007 09:28:19 +0200 Subject: [Rxtx] No blocking read on Windows. Message-ID: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/5d07d571/attachment-0065.html -------------- next part -------------- Hi, I have problem that InputStram.read() (SerialPort)?returns -1 instead blocking and waiting for data. I found that this problem was ?known in 2005 : ? >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > >> Hi Trent >> >> Thanks for the fast response. >> Here's a Q&D test program for the blocking read on windows that just >> attempts to read one byte, and prints the resulting byte. On my system it >> returns -1, where I expect that it keeps waiting for data. >> >This isn't happening on Linux so the bug is in src/termios.c.? I'll have >something this weekend to fix that. I'm using RXTX 2.1.7r2 and the problem still is here. Im using Windows XP and java 1.5 disableReciveTimeout() and disableReciveTreshhold() dont help. ? best regards ? Piotr Zielniok From Adrien.TOS at ingenico.com Wed Mar 28 01:40:46 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Wed, 28 Mar 2007 09:40:46 +0200 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903E88880@frsnprexc1.usr.ingenico.loc> Looking at the code, it seems there is no support for infinite timeout? And maybe the count++ < 20 condition is breaking out of the loop too early? The only condition to break out of the loop should either be the timeout has expired or the number of requested bytes has been received. -----Message d'origine----- De : rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] De la part de Trent Jarvi Envoy? : mardi 27 mars 2007 00:17 ? : RXTX Developers and Users Objet : Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From j.kenneth.gentle at acm.org Wed Mar 28 06:44:15 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 28 Mar 2007 08:44:15 -0400 Subject: [Rxtx] No blocking read on Windows. In-Reply-To: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> References: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> Message-ID: <200703281844.l2SIiITW028614@qbang.org> Just another "ME TOO!" - I'm seeing this problem on Windows XP, jre for windows XP/Embedded. I cranked receiveTimeout up to Integer.MAX_INT, but it doesn't seem to wait that long At 03:28 2007-03-28, you wrote: >Hi, >I have problem that InputStram.read() (SerialPort) returns -1 >instead blocking and waiting for data. I found that this problem >was known in 2005 : > > >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > > > >> Hi Trent > >> > >> Thanks for the fast response. > >> Here's a Q&D test program for the blocking read on windows that just > >> attempts to read one byte, and prints the resulting byte. On my system it > >> returns -1, where I expect that it keeps waiting for data. > >> > > >This isn't happening on Linux so the bug is in src/termios.c. I'll have > >something this weekend to fix that. > >I'm using RXTX 2.1.7r2 and the problem still is here. >Im using Windows XP and java 1.5 >disableReciveTimeout() and disableReciveTreshhold() dont help. > >best regards > >Piotr Zielniok > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From greg.johnson at manchester.ac.uk Wed Mar 28 14:43:29 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Wed, 28 Mar 2007 22:43:29 +0200 Subject: [Rxtx] Cannot close and reopen serial port Message-ID: <377F9765-7A9D-4CE9-9176-FFB63A2594F0@manchester.ac.uk> Dear all, It appears I cannot close a port properly: SerialPort serialport = portid.open("myprog",100); // do some stuff, all works fine serialport.close(); // all seems fine but... SerialPort sp2 = portid.open("myprog",100); throws PortInUseException. And when I dig into the rxtx code, I find in CommPort.java, in close(): CommPortIdentifier cp = CommPortIdentifier.getPortIdentifier(this); (line 64 or there abouts) but this throws a NoSuchPortException which is caught but ignored (line 74ish). Can anyone suggest how this could happen: a port that was valid, opened, and used, throws a NSPE when it comes to closing it? I'm pulling my (remaining) hair out over this one! Cheers, greg PS And thanks for RXTX - it's great to have! PPS (21.-7. winxp/osx both, java 1.5) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/c28852fc/attachment-0064.html From rxtx at vrijheidslaan.net Fri Mar 30 16:52:50 2007 From: rxtx at vrijheidslaan.net (Rob) Date: Fri, 30 Mar 2007 22:52:50 -0000 Subject: [Rxtx] Cvs Question Message-ID: <61896.80.126.150.87.1175295162.squirrel@webmail.provalue.nl> Hi There, Im trying to get the latest version to work on mac osx. Problem is that i can't checkout version 2.1.8. Probably my fault but can some one please give me the alternative commands for: [user at myhost]$ export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot [user at myhost]$ cvs login Thanx, Rob From ra85551 at gmail.com Thu Mar 1 03:47:06 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Thu, 1 Mar 2007 13:47:06 +0300 Subject: [Rxtx] enableReceiveTimeout() issue Message-ID: Hello, world! I found a limitation of 16300 ms for CommPort's enableReceiveTimeout() method, while in original javax.comm docs there are no any references to that. Is that a bug or feature? I actually need longer timeouts sometimees. -- Pavel Parkhomenko From lyon at docjava.com Thu Mar 1 07:54:17 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 01 Mar 2007 09:54:17 -0500 Subject: [Rxtx] parametric singleton design pattern In-Reply-To: References: <22d55aea0702081207q5e7f6785l352d498d6f5f9fb1@mail.gmail.com> <22d55aea0702100034o3bcf42f3j1d1a6257029a67b0@mail.gmail.com> Message-ID: Hi All, I have been thinking about the use of a design pattern to cache resources that are consumed by processes. Toward that end, I have arrived at a parametric singleton design pattern, which I mentioned on this list some time ago. The idea has been published at: http://www.jot.fm/issues/issue_2007_03/column2 I can't help but think that there should be an API available for dealing with the tracking of serial port usage. Perhaps it is a kind of resource manager called the: SerialPortManager basic prototypes already exist in this vain. See, for example: http://www.ce.rit.edu/research/projects/2005_fall/rt_poolsystem/doc/PoolMon/SerialPortManager.html http://www.eventhelix.com/RealtimeMantra/PatternCatalog/serial_port_design_pattern.htm And others shown by a google search on "SerialPortManager" Cheers! - Doug From Eric.Arseneau at sun.com Thu Mar 1 10:15:03 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:15:03 -0800 Subject: [Rxtx] Any known Java 6 issues with RXTX 2.1-7r2 ? Message-ID: <45E70A17.1060206@sun.com> I just did a test on a recent build of Solaris 11 x86 and it seems that I can connect to my serial device fine when Java 5 is the default, but when Java 6 is the default, no go. Any information ? From Eric.Arseneau at sun.com Thu Mar 1 10:19:58 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:19:58 -0800 Subject: [Rxtx] Mac OS X and missing data Message-ID: <45E70B3E.7040908@sun.com> We have a device which is USB based but presents itself as a serial port to a machine. On my MacBook Pro I can get excellent throughput if I get my device to send data as quickly as possible. On the desktop side, if I do an type of disk IO to log the data I get, I end up with some missing data at some point. I hooked up a USB analyzer and did confirm that all the data is sent as expected to the desktop from the device. I found a work around for this, buffer the data in memory and only write the data out when I've received it all. However, when the same code and same device is attempted on a co-workers MacBook Pro (same hardware specs), I get errors and must slow down dramatically the device side's sending of data. Any ideas/recommendations on what I can do to get rid of this error ? From what I can tell, it seems that RXTX is not able to wake up to the interrupts coming in indicating data is ready, quickly enough, is there anything I can do ? From chinkaiw at hotmail.com Fri Mar 2 00:57:43 2007 From: chinkaiw at hotmail.com (Wang Chinkai) Date: Fri, 02 Mar 2007 07:57:43 +0000 Subject: [Rxtx] dynamic detect rs232 port Message-ID: Hi all I have a question about detecting rs232 port dynamicly. I have to aceess some port and detect rs232 port at the same time. Some usb device simulates rs232 port , and I can not know what the port name it gets until it connects,so I have to detect it dynamic,but I have to access another rs232 device at the same time. I found a problem. If I use CommPortIdentifier.getPortIdentifiers() to get new port list , and the other rs232 access function will not close port correctly. So , How can I solve it . Thanks. _________________________________________________________________ ?? 2GB ???? Windows Live Mail ????????????? http://ideas.live.com/programpage.aspx?versionid=5d21c51a-b161-4314-9b0e-4911fb2b2e6d From eu259473 at tele2.it Fri Mar 2 06:16:40 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 02 Mar 2007 14:16:40 +0100 Subject: [Rxtx] rxtx on HP tru 64 unix Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070302/706c7a70/attachment-0092.html From tjarvi at qbang.org Fri Mar 2 08:39:33 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 08:39:33 -0700 (MST) Subject: [Rxtx] rxtx on HP tru 64 unix In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, "Giuseppe Marchese" wrote: > Hi > > I try to install rxtx on hp tru 64 but make fails, > There are somebody that do the same and work. > > > Sorry for may english! > > Hi Giuseppe Could you provide a log of the failure? script ./configure make # use gnu make exit The information will be in the typescript created. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 2 19:56:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 19:56:52 -0700 (MST) Subject: [Rxtx] dynamic detect rs232 port In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, Wang Chinkai wrote: > Hi all > > I have a question about detecting rs232 port dynamicly. > > I have to aceess some port and detect rs232 port at the same time. > Some usb device simulates rs232 port , and I can not know > what the port name it gets until it connects,so I have to detect it > dynamic,but I have to access > another rs232 device at the same time. > > I found a problem. Hi Wang This is a known problem. The code is braindead there. In fact there needs to be events even in a rudamentary way when you add a usb dongle. I'm burried in tasks not far from rxtx but not in rxtx. I can't get to the problem but we would accept patches if you dig into it. [I'm getting to the license question earlier too; I don't have another 10%] -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Fri Mar 2 23:19:01 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 01:19:01 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Hi, Under ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable USB -> serial converter(using virtual com port drivers), with using example code pretty much straight out of http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port opens fine, enumerations all work, etc. My application calls for a large amount of data to be transferred in a short amount of time at 2,000,000 baud. My hardware sends approximately 15,232 bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL converter work fine, and the application works using C++. In C++, I do a hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); to open the port, and a boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); to read the port. The variable buffer fills with the 15238 bytes, and returns. If I do a resultz = is.read(cbuf,0,15238); in java with RXTX where is = new BufferedReader(new InputStreamReader(port.getInputStream())); and where resultz is an int, and cbuf is a char [] cbuf, resultz gets EXACTLY 3968 bytes the first time called. If I call it multiple times, I get roughly 11k total(less than what is sent), never more than the 3968 bytes per is.read() call. My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 bytes. I've played with inputbuffersize, receive threshold, receivetimeout, and so on. The FTDI virtual com port drivers that I'm using are rock solid, and have had zero problems with them using a variety of applications, some of my own, some professionally written, etc. No flow control is used anyplace, no RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. No exceptions are being thrown. What am I doing wrong, and what I can adjust to receive the full 15k bytes in one single read? Thanks! Keith From Eric.Arseneau at sun.com Fri Mar 2 23:32:07 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Fri, 02 Mar 2007 22:32:07 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <45E91667.20501@sun.com> This is the same type of thing that is happening to me on Mac OS X and does not seem to behave the same on different machines. I posted a day or two ago on this with subject "Mac OS X and missing data". Would love to hear if there is a solution to this :) From tjarvi at qbang.org Sat Mar 3 10:54:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 10:54:17 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > Hi, > > Under > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable > USB -> serial converter(using virtual com port drivers), with using example > code pretty much straight out of > http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port > opens fine, enumerations all work, etc. > > My application calls for a large amount of data to be transferred in a short > amount of time at 2,000,000 baud. My hardware sends approximately 15,232 > bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL > converter work fine, and the application works using C++. > > In C++, I do a > > hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, > OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); > > to open the port, and a > > boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); > > to read the port. > > The variable buffer fills with the 15238 bytes, and returns. > > If I do a > > resultz = is.read(cbuf,0,15238); in java with RXTX > > where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > > and where resultz is an int, and cbuf is a char [] cbuf, resultz gets > EXACTLY 3968 bytes the first time called. If I call it multiple times, I get > roughly 11k total(less than what is sent), never more than the 3968 bytes > per is.read() call. > > My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 > bytes. > > I've played with inputbuffersize, receive threshold, receivetimeout, and so > on. The FTDI virtual com port drivers that I'm using are rock solid, and > have had zero problems with them using a variety of applications, some of my > own, some professionally written, etc. No flow control is used anyplace, no > RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. > > No exceptions are being thrown. > > What am I doing wrong, and what I can adjust to receive the full 15k bytes > in one single read? > > Thanks! > Hi Keith I would expect a 20 meg application is going to have different behavior with the OS than a smaller application with respect to the kernel memory managment, schedualing, ... Something subtle could be causing problems. With respect to the recieve timeout and threshold, if you set the timeout to zero and the threshold to the size of data you expect, read should not return until it get that data. You may try with a stand alone application that tests just that with the C/C++ API. If the read is returning with less data when tested for short reads, you have found a bug in the device driver more than likely. The USB dongle vendor would probably be interested in knowing about this. As mentioned, these devices are getting very good; almost bug free. I suspect you found a bug though if you did use the threshold and timeout properly. The missing data is typical when not using flow control. When the OS buffering fills, the hardware will start dropping bytes. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:38:52 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:38:52 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> update: I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now instead of 3968. This makes sense. 128 bytes of overhead + 3968 bytes of data = 4096 transfer size 32 bytes of overhead + 992 bytes of data = 1024 transfer size. 1/4 the data = 1/4 the overhead. I rearranged my reading like so: resultz = is.read(cbuf,0,3968); resultz = is.read(cbuf,3968,3968); resultz = is.read(cbuf,7936,3968); while (!(is.ready())); // wait for ready resultz = is.read(cbuf,11904,3334); and this grabs 15,238 bytes total. BUT, I still have the quandry of the screwed up multi-bytes. I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. Approx 8% of the data. The bad bytes always seem to take the flavor of 0x2018, 0x2019, x2022, x2030, x201d. Are these maybe errors and I don't know what they enumerate to? I still can't believe some other layer isn't handling putting those bytes together all in one stream for me. Thanks Keith ----- Original Message ----- From: "Keith" To: "Bob Jacobsen" ; "RXTX Developers and Users" Sent: Saturday, March 03, 2007 11:26 AM Subject: Re: [Rxtx] is.read() only returning 3968 bytes > Bob, > > > Interesting numerical coincidence is that (max USB transfer) - (what > > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > > needed to transfer that much data. > > I was thinking along the same lines. I don't know USB well, but I do know > that those numbers were close enough to warrant investigating the > relationship between them. > > > I think what you're seeing is the internal buffering of the USB data > > stream. You'll need some form of higher-level buffering to smooth > > that out. > > Shouldn't the InputStreamReader() and BufferedReader() provide this type of > buffering? Isn't that the idea behind those? > > > All hypotheses need to be tested. In this case, a test would be to > > check for missing data. If this idea is right, you'll get _all_ the > > data, but you won't be missing characters. > > I did start looking at the data. -- I'm getting weird results. > > I tried this: > > loopzz = 0; > > for (looptwo = 0; looptwo < 100000; looptwo++) { > while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > > }} > > So I'm reading one character at a time. The good news is that loopzz is > exactly 15238 at the end of the routine, which is perfectly correct. I > picked looptwo value out of thin air. > > The weird results come in terms of the values, the data isn't correct at > least in one case. Look here: > > 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > > This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). > But the 0x89 was replaced by 0x2030. Why the heck would the returned value > be 0x2030?? Why is the returned byte completely out of range? Why the > multibyte return? > > From InputStream in the API: > > read > public abstract int read() > throws IOExceptionReads the next byte of data from the > input stream. The value byte is returned as an int in the range 0 to 255. If > no byte is available because the end of the stream has been reached, the > value -1 is returned. This method blocks until input data is available, the > end of the stream is detected, or an exception is thrown. > Value should be 0-255. > > > In my application time is really critical, reading 1 byte at a time is > probably not going to work. > > Thanks Eric & Bob for looking at this. > > Keith > From tjarvi at qbang.org Sat Mar 3 12:52:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 12:52:27 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > update: > > I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now > instead of 3968. > > This makes sense. > > 128 bytes of overhead + 3968 bytes of data = 4096 transfer size > 32 bytes of overhead + 992 bytes of data = 1024 transfer size. > > 1/4 the data = 1/4 the overhead. > > I rearranged my reading like so: > > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. > Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? > > I still can't believe some other layer isn't handling putting those bytes > together all in one stream for me. > The layer for this in Serial land is flow control. Software and hardware flow control prevent the overruns you observe. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:54:41 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:54:41 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <001a01c75dcd$c8802a70$6600a8c0@jbh757ktruws7g> Trent, Thanks for taking the time to reply. > I would expect a 20 meg application is going to have different behavior > with the OS than a smaller application with respect to the kernel memory > managment, schedualing, ... Something subtle could be causing problems. Well, at least I know the VCP drivers, the OS, etc can handle 2mbps reliably. Without hiccuping or dropping bytes. The C++ code works reliably without flow control. > The missing data is typical when not using flow control. When the OS > buffering fills, the hardware will start dropping bytes. I'm actually not getting MISSING data, I'm getting CORRUPTED data. If you look at my most recent post, I'm getting these bad bytes in place of the correct values: 0x2018, 0x2019, x2022, x2030, x201d. Why would is.read() return values not in the range of 0-255 ? Thanks. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 08:59:14 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 07:59:14 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: At 1:19 AM -0500 3/3/07, Keith wrote: >If I do a > >resultz = is.read(cbuf,0,15238); in java with RXTX > >where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > >and where resultz is an int, and cbuf is a char [] cbuf, resultz gets >EXACTLY 3968 bytes the first time called. If I call it multiple times, I get >roughly 11k total(less than what is sent), never more than the 3968 bytes >per is.read() call. > >My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 >bytes. Interesting numerical coincidence is that (max USB transfer) - (what you get) = 4096-3968 = 128 bytes is (almost) the size of the headers needed to transfer that much data. I think what you're seeing is the internal buffering of the USB data stream. You'll need some form of higher-level buffering to smooth that out. All hypotheses need to be tested. In this case, a test would be to check for missing data. If this idea is right, you'll get _all_ the data, but you won't be missing characters. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 09:26:14 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 11:26:14 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Bob, > Interesting numerical coincidence is that (max USB transfer) - (what > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > needed to transfer that much data. I was thinking along the same lines. I don't know USB well, but I do know that those numbers were close enough to warrant investigating the relationship between them. > I think what you're seeing is the internal buffering of the USB data > stream. You'll need some form of higher-level buffering to smooth > that out. Shouldn't the InputStreamReader() and BufferedReader() provide this type of buffering? Isn't that the idea behind those? > All hypotheses need to be tested. In this case, a test would be to > check for missing data. If this idea is right, you'll get _all_ the > data, but you won't be missing characters. I did start looking at the data. -- I'm getting weird results. I tried this: loopzz = 0; for (looptwo = 0; looptwo < 100000; looptwo++) { while (is.ready()) { cbuf[loopzz] = (char) is.read(); loopzz++; }} So I'm reading one character at a time. The good news is that loopzz is exactly 15238 at the end of the routine, which is perfectly correct. I picked looptwo value out of thin air. The weird results come in terms of the values, the data isn't correct at least in one case. Look here: 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). But the 0x89 was replaced by 0x2030. Why the heck would the returned value be 0x2030?? Why is the returned byte completely out of range? Why the multibyte return? >From InputStream in the API: read public abstract int read() throws IOExceptionReads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown. Value should be 0-255. In my application time is really critical, reading 1 byte at a time is probably not going to work. Thanks Eric & Bob for looking at this. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 14:44:50 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 13:44:50 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: Java's "char" type is Unicode. I think what you're seeing is a bug in the byte -> Unicode translation. 0x2018, 0x2019 are the curly open and close quotes. There used to be (and might still be) bugs in the conversion of these in a couple of libc versions. Some of the ASCII -> ISO and ISO -> ASCII routines were a little over-ambitious with respect to handling the open and close quotes, and tried to convert them to the "curly" form inappropriately. Try _not_ casting it to char. Bob At 11:26 AM -0500 3/3/07, Keith wrote: >Bob, > >> Interesting numerical coincidence is that (max USB transfer) - (what >> you get) = 4096-3968 = 128 bytes is (almost) the size of the headers >> needed to transfer that much data. > >I was thinking along the same lines. I don't know USB well, but I do know >that those numbers were close enough to warrant investigating the >relationship between them. > >> I think what you're seeing is the internal buffering of the USB data >> stream. You'll need some form of higher-level buffering to smooth >> that out. > >Shouldn't the InputStreamReader() and BufferedReader() provide this type of >buffering? Isn't that the idea behind those? > >> All hypotheses need to be tested. In this case, a test would be to >> check for missing data. If this idea is right, you'll get _all_ the >> data, but you won't be missing characters. > >I did start looking at the data. -- I'm getting weird results. > >I tried this: > >loopzz = 0; > >for (looptwo = 0; looptwo < 100000; looptwo++) { >while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > >}} > >So I'm reading one character at a time. The good news is that loopzz is >exactly 15238 at the end of the routine, which is perfectly correct. I >picked looptwo value out of thin air. > >The weird results come in terms of the values, the data isn't correct at >least in one case. Look here: > >0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > >This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). >But the 0x89 was replaced by 0x2030. Why the heck would the returned value >be 0x2030?? Why is the returned byte completely out of range? Why the >multibyte return? > >>From InputStream in the API: > >read >public abstract int read() > throws IOExceptionReads the next byte of data from the >input stream. The value byte is returned as an int in the range 0 to 255. If >no byte is available because the end of the stream has been reached, the >value -1 is returned. This method blocks until input data is available, the >end of the stream is detected, or an exception is thrown. >Value should be 0-255. > > >In my application time is really critical, reading 1 byte at a time is >probably not going to work. > >Thanks Eric & Bob for looking at this. > >Keith > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 15:10:11 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 17:10:11 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Bob said ..... > Java's "char" type is Unicode. I think what you're seeing is a bug > in the byte -> Unicode translation. Bob -- I think you hit the nail on the head. I was just coming to the same realization here. I knew that something funny was going on because the same bytes always got "corrupted." I'm pretty sure its in the InputStreamReader() functionality where the conversion junk is happening. Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. I don't know if simply changing the cast is going to work. Since the conversion is happening upstream (pun intended), I don't think my cast is doing this. Also I think the compiler forced me to use the cast. I'm still playing around, and I'll report back once I nail it down. Thanks!! Keith From tjarvi at qbang.org Sat Mar 3 15:59:46 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 15:59:46 -0700 (MST) Subject: [Rxtx] Win64 rxtx Testers? Message-ID: I have compiled win64 binaries of rxtx. Are there any users interested in testing them? If so, I'll look into putting them on the web site. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Mar 3 15:35:06 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 14:35:06 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: Because of this and similar problems, JMRI does all it's serial IO using +only+ byte values. It's a but of a pain, as Java wants to go to char and int types a little too aggressively, but it does solve the "uncontrolled conversions" problems. Bob At 5:10 PM -0500 3/3/07, Keith wrote: >Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > >Bob -- I think you hit the nail on the head. > >I was just coming to the same realization here. I knew that something funny >was going on because the same bytes always got "corrupted." > >I'm pretty sure its in the InputStreamReader() functionality where the >conversion junk is happening. > >Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > >I don't know if simply changing the cast is going to work. Since the >conversion is happening upstream (pun intended), I don't think my cast is >doing this. Also I think the compiler forced me to use the cast. -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mark at mdsh.com Sun Mar 4 11:01:33 2007 From: mark at mdsh.com (Mark Himsley) Date: Sun, 04 Mar 2007 18:01:33 +0000 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: <5C01AC72C200388815C04982@bedroom.mdsh.local> On 03 March 2007 14:38 -0500 Keith wrote: > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT > consistent. Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? It looks like you need to use DataInputStream and DataOutputStream. -- Mark Himsley From tjarvi at qbang.org Sun Mar 4 11:35:08 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 11:35:08 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" > > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > > * Line #21 - Not sure if you need a (TM) mark for > the term "Sun" > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > OK. I'm going through this today. Some groups ask if rxtx could be under their license also. I think this is a good example of why I resist multiple licenses and focus on why the current license may not be usable by them. The RXTX project is a convergence of hobby and commercial interests. I happen to do both right now. The problem with licensing is we have to stay on top of them as they change. Clearly, adding more licenses will not make this easier. I'm acting as the hobby person today. RXTX always favors the hobby people. But as we move forward, I'm going to need to bring this to lawyers at work and explain to them what is going on. Others here may have to do this also. I don't anticipate problems or unexpected changes. The goal is a consistant, comprehendable and usable license as close to what we have now as possible. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 14:52:10 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 14:52:10 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (1/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: I'm breaking this into two parts. I expect the second part will need more attention. Comments first, then the changed material below. On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > Thanks > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. OK. RXTX for consitent use. java should not be capitalized because it does not only mean Sun [TM] Java [TM]. An example of this not meaning Java is when people use RXTX with GCJ. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". There are not any contributors that are in all of RXTX yet but I did update the comment to try to reflect the current situation without making it a nightmare to maintain. I looked to see how the Linux kernel does it as a reference point. > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" The URL can be problematic. I have done so below with a time reference. GNU does not provide version information in their URLS. I picture this being a problem when the version 3 comes out. > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > This will be corrected when the copy is updated to the version linked below. ---------------- begin proposed material involved -------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. ----------------- end proposed material involved -------------------- I'll be looking at the linking issue again next. That should be all that remains other than including the 2.1 version. Let me know if you have problems with anything here. I do not want to dilute the material I post next with these housekeeping tasks. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 16:08:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 16:08:36 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: For those that are wondering what is going on here, this next bit is the meat of the changes. We agreed a long time ago to put this disclaimer in. We did a so so job. It was in rxtx 2.0, not well written, ... So some groups using rxtx that would like to ship rxtx so users don't need to download, install, go to the mail-list to find why it failed, ... Then their legal teams tell them section 5 paragraph 2 is a show stopper. That was never the intent. Now going through what remains... > and might need a (TM) suffix to make Sun happy. Added disclaimer at the ended 'all trademarks belong...' > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. OK. As you can see I was trying to adjust GNU text there for the LGPL. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. used dynamically linked terminology. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". I tried to address this more upfront with an intent statement. Let me know if you have problems with it. I also tried to make it a little more clear what was derived from the GNU solution by moving the link location closer to GNU's suggestion. > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > Thats the intent. Here is the combined fixes. Note that only the material in /*-- --*/ is being touched. The new GPL license is there but unmodified. ------------------------ begin proposed new license ------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. | | An executable that contains no derivative of any portion of RXTX, but | is designed to work with RXTX by being dynamically linked with it, | is considered a "work that uses the Library" subject to the terms and | conditions of the GNU Lesser General Public License. | | The following has been added to the RXTX License to remove | any confusion about linking to RXTX. We want to allow in part what | section 5, paragraph 2 of the LGPL does not permit in the special | case of linking over a controlled interface. The intent is to add a | Java Specification Request or standards body defined interface in the | future as another exception but one is not currently available. | | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface | | As a special exception, the copyright holders of RXTX give you | permission to link RXTX with independent modules that communicate with | RXTX solely through the Sun Microsytems CommAPI interface version 2, | regardless of the license terms of these independent modules, and to copy | and distribute the resulting combined work under terms of your choice, | provided that every copy of the combined work is accompanied by a complete | copy of the source code of RXTX (the version of RXTX used to produce the | combined work), being distributed under the terms of the GNU Lesser General | Public License plus this exception. An independent module is a | module which is not derived from or based on RXTX. | | Note that people who make modified versions of RXTX are not obligated | to grant this special exception for their modified versions; it is | their choice whether to do so. The GNU Lesser General Public License | gives permission to release a modified version without this exception; this | exception also makes it possible to release a modified version which | carries forward this exception. | | You should have received a copy of the GNU Lesser General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA | All trademarks belong to their respective owners. --------------------------------------------------------------------------*/ The original GNU Lesser General Public License Follows. GNU LESSER GENERAL PUBLIC LICENSE Version 2.1, February 1999 Copyright (C) 1991, 1999 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. [This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence the version number 2.1.] Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This license, the Lesser General Public License, applies to some specially designated software packages--typically libraries--of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below. When we speak of free software, we are referring to freedom of use, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish); that you receive source code or can get it if you want it; that you can change the software and use pieces of it in new free programs; and that you are informed that you can do these things. To protect your rights, we need to make restrictions that forbid distributors to deny you these rights or to ask you to surrender these rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library or if you modify it. For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights. We protect your rights with a two-step method: (1) we copyright the library, and (2) we offer you this license, which gives you legal permission to copy, distribute and/or modify the library. To protect each distributor, we want to make it very clear that there is no warranty for the free library. Also, if the library is modified by someone else and passed on, the recipients should know that what they have is not the original version, so that the original author's reputation will not be affected by problems that might be introduced by others. Finally, software patents pose a constant threat to the existence of any free program. We wish to make sure that a company cannot effectively restrict the users of a free program by obtaining a restrictive license from a patent holder. Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license. Most GNU software, including some libraries, is covered by the ordinary GNU General Public License. This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs. When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library. We call this license the "Lesser" General Public License because it does Less to protect the user's freedom than the ordinary General Public License. It also provides other free software developers Less of an advantage over competing non-free programs. These disadvantages are the reason we use the ordinary General Public License for many libraries. However, the Lesser license provides advantages in certain special circumstances. For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License. In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software. For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU operating system, as well as its variant, the GNU/Linux operating system. Although the Lesser General Public License is Less protective of the users' freedom, it does ensure that the user of a program that is linked with the Library has the freedom and the wherewithal to run that program using a modified version of the Library. The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, whereas the latter must be combined with the library in order to run. GNU LESSER GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License Agreement applies to any software library or other program which contains a notice placed by the copyright holder or other authorized party saying it may be distributed under the terms of this Lesser General Public License (also called "this License"). Each licensee is addressed as "you". A "library" means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables. The "Library", below, refers to any such software library or work which has been distributed under these terms. A "work based on the Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term "modification".) "Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library. Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does. 1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) The modified work must itself be a software library. b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change. c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License. d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful. (For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library. In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. 4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange. If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code. 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables. When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law. If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.) Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself. 6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications. You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things: a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.) b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. c) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution. d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place. e) Verify that the user has already received a copy of these materials or that you have already sent this user a copy. For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute. 7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things: a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above. b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work. 8. You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 9. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Library (or any work based on the Library), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Library or works based on it. 10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties with this License. 11. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply, and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 12. If the distribution and/or use of the Library is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Library under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 13. The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation. 14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Libraries If you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the ordinary General Public License). To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Also add information on how to contact you by electronic and paper mail. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the library, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the library `Frob' (a library for tweaking knobs) written by James Random Hacker. , 1 April 1990 Ty Coon, President of Vice That's all there is to it! ------------------------ end of proposed license ------------------ -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sun Mar 4 16:26:04 2007 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 04 Mar 2007 17:26:04 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <45EB558C.3010609@cox.net> Bob Jacobsen wrote: > Because of this and similar problems, JMRI does all it's serial IO > using +only+ byte values. It's a but of a pain, as Java wants to go > to char and int types a little too aggressively, but it does solve > the "uncontrolled conversions" problems. Anytime that you are reading bytes of data that is not printable, unicode text, in Java, you really need to stay away from the Readers. Use input stream only, or you will see unicode valued byte groups converted to unicode "char" values. Gregg Wonderly From joachim at buechse.de Mon Mar 5 04:23:48 2007 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 5 Mar 2007 12:23:48 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> The behaviour is exactly what you asked for in you code. is = new BufferedReader(new InputStreamReader(port.getInputStream())); Readers return Text (ie unicode chars) not bytes. You instantiate the InputStreamReader without saying which charset you want, which means "platform default". As this is on Windows, it will convert Windows characters to equivalent unicode characters. If you want to read bytes, read bytes not Text. Reading bytes is done with InputStream and BufferedInputStream. BTW: The InputStream and Reader methods that read arrays are not guarenteed to fill up the array. You always have to check what you really got, and advance your index accordingly. A typical "read up to 32k" method looks like this: InputStream is= ... // -- determine the max buffer size int len= is.available(); if (len == 0) { len= 32 * 1024; } // -- read all available data byte[] buffer= new byte[len]; int pos= 0; int read; do { read= is.read(buffer, pos, buffer.length - pos); pos= pos + read; } while (read != -1 && pos < buffer.length); Best regards, Joachim --- Joachim B?chse Phone: +41 44 500 2604 Buechse Consulting Hadlaubsteig 2 CH-8006 Z?rich On 03.03.2007, at 23:10, Keith wrote: > Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > > Bob -- I think you hit the nail on the head. > > I was just coming to the same realization here. I knew that > something funny > was going on because the same bytes always got "corrupted." > > I'm pretty sure its in the InputStreamReader() functionality where the > conversion junk is happening. > > Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > > I don't know if simply changing the cast is going to work. Since the > conversion is happening upstream (pun intended), I don't think my > cast is > doing this. Also I think the compiler forced me to use the cast. > > I'm still playing around, and I'll report back once I nail it down. > > Thanks!! > > Keith > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Mon Mar 5 07:25:46 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 05 Mar 2007 08:25:46 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> Message-ID: <45EC286A.8060608@cox.net> Joachim Buechse wrote: > BTW: The InputStream and Reader methods that read arrays are not > guarenteed to fill up the array. You always have to check what you > really got, and advance your index accordingly. A typical "read up to > 32k" method looks like this: > > InputStream is= ... > // -- determine the max buffer size > int len= is.available(); > if (len == 0) { > len= 32 * 1024; > } > // -- read all available data > byte[] buffer= new byte[len]; > int pos= 0; > int read; > do { > read= is.read(buffer, pos, buffer.length - pos); > pos= pos + read; > } while (read != -1 && pos < buffer.length); > My preferred structure is. byte arr[ len ]; int cnt; int off = 0; while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { off += cnt; } This keeps you from adding -1 to pos when the read returns -1. It also skips out when the read is 0 bytes which, is not a described EOF in InputStream java docs, but is a condition I want to be aware of. Gregg Wonderly From joachim at buechse.de Tue Mar 6 02:52:58 2007 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 6 Mar 2007 10:52:58 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <45EC286A.8060608@cox.net> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: The code I copied was from a file resource reader, it shouldn't really be applied to networking/external IO code. Mea culpa. However aborting when you get 0 from read is not always what you want either (you kind of indicated that already). Some unix java implementations will return 0 if the kernel read was aborted with EINTER, which is rarely the point where you want to abort your read - at least not without further checks. A "complete" solution always depends on the events you need to handle and the time the total read could take in reality. In some cases it's worth checking Thread.isInterrupted() in the loop, some code re-loops on 0 but only a limited number of times, some check a total timeout limit, etc... Best regards, Joachim On 05.03.2007, at 15:25, Gregg Wonderly wrote: > My preferred structure is. > > byte arr[ len ]; > int cnt; > int off = 0; > while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { > off += cnt; > } > > This keeps you from adding -1 to pos when the read returns -1. It > also skips > out when the read is 0 bytes which, is not a described EOF in > InputStream java > docs, but is a condition I want to be aware of. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Mar 6 14:47:44 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 Mar 2007 14:47:44 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: Just FYI, rxtx will usually not break out on EINTER. The code in the native library usually does something close to this: do { read(...) } while ( !done && errno==EINTR ); Obviously there is a little more involved but it will retry on EINTER if not done. On Tue, 6 Mar 2007, Joachim Buechse wrote: > The code I copied was from a file resource reader, it shouldn't > really be applied to networking/external IO code. Mea culpa. > > However aborting when you get 0 from read is not always what you want > either (you kind of indicated that already). Some unix java > implementations will return 0 if the kernel read was aborted with > EINTER, which is rarely the point where you want to abort your read - > at least not without further checks. A "complete" solution always > depends on the events you need to handle and the time the total read > could take in reality. In some cases it's worth checking > Thread.isInterrupted() in the loop, some code re-loops on 0 but only > a limited number of times, some check a total timeout limit, etc... > > Best regards, > Joachim > > On 05.03.2007, at 15:25, Gregg Wonderly wrote: >> My preferred structure is. >> >> byte arr[ len ]; >> int cnt; >> int off = 0; >> while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { >> off += cnt; >> } >> >> This keeps you from adding -1 to pos when the read returns -1. It >> also skips >> out when the read is 0 bytes which, is not a described EOF in >> InputStream java >> docs, but is a condition I want to be aware of. >> >> Gregg Wonderly >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 gjhanna at gmail.com Thu Mar 8 13:42:52 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Fri, 9 Mar 2007 09:42:52 +1300 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? Message-ID: I've just struck an issue using rxtx in a multi-threaded environment: If I have 3 threads trying to open *the same* comm-port I get a deadlock in CommPortIdentifier.open If I have just 2, it works fine - I get a PortInUseException which is nice and I can handle it. The 3 thread->deadlock thing is causing me issues. (Sample code below). This is from the java thread-dump Found one Java-level deadlock: ============================= "Thread-2": waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object ), which is held by "Thread-1" "Thread-1": waiting to lock monitor 0x0003e9cc (object 0x2450e108, a gnu.io.CommPortIdentifier), which is held by "Thread-2" Java stack information for the threads listed above: =================================================== "Thread-2": at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:329) - waiting to lock <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) "Thread-1": at java.lang.Object.wait(Native Method) - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) - locked <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) (Apart from this, rxtx is working fantastically for us). I'm thinking I'll have to implement some sort of locking mechanism that *doesn't* use java synchronization to prevent this situation. (Which doesn't sound like a good idea to me). Any ideas? Thanks, Greg Hanna ============= RXTXLockTest.java ======================================== import gnu.io.CommPort; import gnu.io.CommPortIdentifier; /** * @author Greg Hanna * Minimal code to create a deadlock with rxtx in multithreaded open */ public class RXTXLockTest { public static void main(String[] args) { try { CommPortIdentifier cpiCom1 = CommPortIdentifier.getPortIdentifier ("COM14"); OpenThread t1 = new OpenThread (" one ", cpiCom1); OpenThread t2 = new OpenThread (" two ", cpiCom1); OpenThread t3 = new OpenThread (" 003 ", cpiCom1); t1.start(); t2.start(); t3.start(); // comment this out and it runs with (expected) PortInUseException } catch (Exception e) { e.printStackTrace(); } } } class OpenThread extends Thread { String name; CommPortIdentifier cpi; CommPort cp; public OpenThread (String name, CommPortIdentifier cpi) { this.name = name; this.cpi = cpi; System.out.println (System.currentTimeMillis() + name + " thread created"); } public void run () { try { System.out.println (System.currentTimeMillis() + name + " opening"); cp = cpi.open(name, 2000); System.out.println (System.currentTimeMillis() + name + " opened - sleeping"); sleep (2000); // do the serial comms with the device. System.out.println (System.currentTimeMillis() + name + " slept - closing"); cp.close(); System.out.println (System.currentTimeMillis() + name + " closed - exiting"); } catch (Exception e) { System.out.println ("Error in thread: " + name ); e.printStackTrace(); } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070308/d9a163c5/attachment-0085.html From eu259473 at tele2.it Fri Mar 9 02:46:20 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 09 Mar 2007 10:46:20 +0100 Subject: [Rxtx] rxtx: tru64 unix make fails Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070309/3b654523/attachment-0085.html From lyon at docjava.com Fri Mar 9 03:58:32 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 Mar 2007 05:58:32 -0500 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi All, The deadlock issue is one that I have been thinking about for some time now. It seems to me that we need a resource manager that enables assignment to a known process. The one thing that seems important about serial ports is that two applications should not use the same serial port at the same time. When this happens, it throws an exception. OK. The exception is a response to a lock condition that arises from an unavailable resource. An abstract implementation (not born of native methods) might assign a serial port to an application, until the application releases it (or is forced to release it by some kill mechanism). Some resources (like a registry) can be reused. But others, like the serial port, cannot. In the case of the serial port, we would like, I think, to have the flyweight design pattern without sharing and with object assignment tracking. A means of breaking deadlock (like a leasing mechanism) seems very useful, to me. My guess is that we can serialize the state of the Parametric Singleton Pattern (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) into the Preferences of the System. Preferences.systemRoot() might help with that. When a resource is checked out, the lease time and owner are listed. A thread that does this can be killed, but applications outside of Java are problematic. There is a compelling problem here. It is not just serial ports. Sound cards, cameras, microphones, files, tape drives, etc. All are consumed resources that are assigned to an application (or user) and deprive other applications, or users, from use. What, if anything, should we do? At present we throw PortInUseExceptions. Is that it? Can we do better? OK, the port is in use. Now what? Do I have to be root to go remove lock files and kill applications? Is there a better way? Thanks! - Doug >I've just struck an issue using rxtx in a multi-threaded environment: > >If I have 3 threads trying to open *the same* >comm-port I get a deadlock in >CommPortIdentifier.open >If I have just 2, it works fine - I get a >PortInUseException which is nice and I can >handle it. > >The 3 thread->deadlock thing is causing me issues. >(Sample code below). > >This is from the java thread-dump > >Found one Java-level deadlock: >============================= >"Thread-2": > waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), > which is held by "Thread-1" >"Thread-1": > waiting to lock monitor 0x0003e9cc (object >0x2450e108, a gnu.io.CommPortIdentifier ), > which is held by "Thread-2" > >Java stack information for the threads listed above: >=================================================== >"Thread-2": > at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) > - waiting to lock <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) >"Thread-1": > at java.lang.Object.wait(Native Method) > - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) > - locked <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) > > >(Apart from this, rxtx is working fantastically for us). > >I'm thinking I'll have to implement some sort of >locking mechanism that *doesn't* use java >synchronization to prevent this situation. >(Which doesn't sound like a good idea to me). > >Any ideas? > >Thanks, > >Greg Hanna > >============= RXTXLockTest.java ======================================== > >import gnu.io.CommPort; >import gnu.io.CommPortIdentifier; > >/** > * @author Greg Hanna > * Minimal code to create a deadlock with rxtx in multithreaded open > */ >public class RXTXLockTest { > ? > ?public static void main(String[] args) { > ?try { > ?CommPortIdentifier cpiCom1 = >CommPortIdentifier.getPortIdentifier ("COM14"); > ?OpenThread t1 = new OpenThread (" one ", cpiCom1); > ?OpenThread t2 = new OpenThread (" two ", cpiCom1); > ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); > ?t1.start(); > ?t2.start(); > ?t3.start(); // comment this out >and it runs with (expected) PortInUseException > ?} catch (Exception e) { > ?e.printStackTrace(); > ?} > ?} >} > >class OpenThread extends Thread { > ?String name; > ?CommPortIdentifier cpi; > ?CommPort cp; > ?public OpenThread (String name, CommPortIdentifier cpi) { > ? this.name = name; > ?this.cpi = cpi; > ?System.out.println >(System.currentTimeMillis() + name + " thread >created"); > ?} > ?public void run () { > ?try { > ?System.out.println >(System.currentTimeMillis() + name + " opening"); > ?cp = cpi.open(name, 2000); > ?System.out.println >(System.currentTimeMillis() + name + " opened - >sleeping"); > ?sleep (2000); // do the serial comms with the device. > ?System.out.println >(System.currentTimeMillis() + name + " slept - >closing"); > ?cp.close(); > ?System.out.println >(System.currentTimeMillis() + name + " closed - >exiting"); > ?} catch (Exception e) { > System.out.println ("Error in thread: " + name ); > ?e.printStackTrace(); > ?} > ?} >} > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Mar 9 06:37:45 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 Mar 2007 06:37:45 -0700 (MST) Subject: [Rxtx] rxtx: tru64 unix make fails In-Reply-To: References: Message-ID: On Fri, 9 Mar 2007, "Giuseppe Marchese" wrote: > Sorry for delay. > ? > This is log for ./configure and make > error. > ? > thanks for attention > ? > Make: '%.java,$(TOP)/$(CLASSDEST)/%.class,$(wildcard $(SPATH)/*.java)': extra chars.? > Stop. > Hi Giuseppe You need to use GNU make with the Makefile. I suspect the tru64 make is not happy with those rules. > configure: exit 0 Looks like configure is fairly happy. From tjarvi at qbang.org Sat Mar 10 07:43:51 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 07:43:51 -0700 (MST) Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi Doug I have very little time to look into this further but what we could do is open up an rxtx 3 devel branch in which a proof of concept could be worked on. It could be the proof of concept for a JSR others including Sun could look at/work on or parts of it could be recycled in a JSR. I'm working very hard on rxtx right now but it does not show. I'm looking at win64, mac intel/ppc, usb bluetooth and usb serial dongles. Some are going to be more tested than others but they are all on the plate. I'll be pushing all the fixes upstream when they are done. So I'm very busy in 2.1 but we could open a new branch. On Fri, 9 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > The deadlock issue is one that I have been thinking about > for some time now. > It seems to me that we need a resource manager that enables assignment > to a known process. > > The one thing that seems important about serial > ports is that two applications should not use the > same serial port at the same time. When this > happens, it throws an exception. > OK. > > The exception is a response to a lock condition that > arises from an unavailable resource. > > An abstract implementation (not born of native methods) might > assign a serial port to an application, until the > application releases it (or is forced to release > it by some kill mechanism). > > Some resources (like a registry) can be reused. > But others, like the serial port, > cannot. > > In the case of the serial port, we would like, I think, to > have the flyweight design pattern > without sharing and with object assignment tracking. > A means of breaking deadlock (like a leasing > mechanism) seems very useful, to me. > > My guess is that we can serialize the state of the Parametric Singleton Pattern > (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) > into the Preferences of the System. Preferences.systemRoot() might help > with that. When a resource is checked out, the lease time and owner are > listed. A thread that does this can be killed, but applications outside of Java > are problematic. > > There is a compelling problem here. It is not just serial ports. > Sound cards, cameras, microphones, files, tape drives, etc. All are consumed > resources that are assigned to an application (or > user) and deprive other applications, > or users, from use. > > What, if anything, should we do? At present we throw PortInUseExceptions. > Is that it? > Can we do better? > OK, the port is in use. Now what? > Do I have to be root to go remove lock files and kill applications? > Is there a better way? > > Thanks! > - Doug > >> I've just struck an issue using rxtx in a multi-threaded environment: >> >> If I have 3 threads trying to open *the same* >> comm-port I get a deadlock in >> CommPortIdentifier.open >> If I have just 2, it works fine - I get a >> PortInUseException which is nice and I can >> handle it. >> >> The 3 thread->deadlock thing is causing me issues. >> (Sample code below). >> >> This is from the java thread-dump >> >> Found one Java-level deadlock: >> ============================= >> "Thread-2": >> waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), >> which is held by "Thread-1" >> "Thread-1": >> waiting to lock monitor 0x0003e9cc (object >> 0x2450e108, a gnu.io.CommPortIdentifier ), >> which is held by "Thread-2" >> >> Java stack information for the threads listed above: >> =================================================== >> "Thread-2": >> at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) >> - waiting to lock <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> "Thread-1": >> at java.lang.Object.wait(Native Method) >> - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) >> - locked <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> >> >> (Apart from this, rxtx is working fantastically for us). >> >> I'm thinking I'll have to implement some sort of >> locking mechanism that *doesn't* use java >> synchronization to prevent this situation. >> (Which doesn't sound like a good idea to me). >> >> Any ideas? >> >> Thanks, >> >> Greg Hanna >> >> ============= RXTXLockTest.java ======================================== >> >> import gnu.io.CommPort; >> import gnu.io.CommPortIdentifier; >> >> /** >> * @author Greg Hanna >> * Minimal code to create a deadlock with rxtx in multithreaded open >> */ >> public class RXTXLockTest { >> ? >> ?public static void main(String[] args) { >> ?try { >> ?CommPortIdentifier cpiCom1 = >> CommPortIdentifier.getPortIdentifier ("COM14"); >> ?OpenThread t1 = new OpenThread (" one ", cpiCom1); >> ?OpenThread t2 = new OpenThread (" two ", cpiCom1); >> ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); >> ?t1.start(); >> ?t2.start(); >> ?t3.start(); // comment this out >> and it runs with (expected) PortInUseException >> ?} catch (Exception e) { >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> class OpenThread extends Thread { >> ?String name; >> ?CommPortIdentifier cpi; >> ?CommPort cp; >> ?public OpenThread (String name, CommPortIdentifier cpi) { >> ? this.name = name; >> ?this.cpi = cpi; >> ?System.out.println >> (System.currentTimeMillis() + name + " thread >> created"); >> ?} >> ?public void run () { >> ?try { >> ?System.out.println >> (System.currentTimeMillis() + name + " opening"); >> ?cp = cpi.open(name, 2000); >> ?System.out.println >> (System.currentTimeMillis() + name + " opened - >> sleeping"); >> ?sleep (2000); // do the serial comms with the device. >> ?System.out.println >> (System.currentTimeMillis() + name + " slept - >> closing"); >> ?cp.close(); >> ?System.out.println >> (System.currentTimeMillis() + name + " closed - >> exiting"); >> ?} catch (Exception e) { >> System.out.println ("Error in thread: " + name ); >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 mm at UDel.Edu Sat Mar 10 14:48:32 2007 From: mm at UDel.Edu (Mike Markowski) Date: Sat, 10 Mar 2007 16:48:32 -0500 Subject: [Rxtx] rxtx and Sun's comm api Message-ID: <45F327B0.2060004@udel.edu> Hi all, I joined the list a few days ago and apologize for what is likely a frequently asked question, though I haven't yet found it anywhere. I learned about rxtx.org through the readme on Sun's version 2 of their comms api. They give recommendations in that readme regarding how a better comms api should be written. Is this the aim of rxtx.org? I wrote an app on my linux box using the Sun comms api (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the fact that only linux and Solaris are supported. So I'm glad to find rxtx.org and am just reading up on how make the conversion so Windows users will be able to run the program as well. At the same time I'm just curious if rxtx.org and Sun are both heading in the same direction. Thanks for any background or historical info. Feel free to point me to any www pages if my googling has just completely missed the target! Thanks again, Mike From tjarvi at qbang.org Sat Mar 10 15:35:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 15:35:25 -0700 (MST) Subject: [Rxtx] rxtx and Sun's comm api In-Reply-To: <45F327B0.2060004@udel.edu> References: <45F327B0.2060004@udel.edu> Message-ID: On Sat, 10 Mar 2007, Mike Markowski wrote: > Hi all, > > I joined the list a few days ago and apologize for what is likely a > frequently asked question, though I haven't yet found it anywhere. I > learned about rxtx.org through the readme on Sun's version 2 of their > comms api. They give recommendations in that readme regarding how a > better comms api should be written. Is this the aim of rxtx.org? > > I wrote an app on my linux box using the Sun comms api > (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the > fact that only linux and Solaris are supported. So I'm glad to find > rxtx.org and am just reading up on how make the conversion so Windows > users will be able to run the program as well. At the same time I'm > just curious if rxtx.org and Sun are both heading in the same direction. > > Thanks for any background or historical info. Feel free to point me to > any www pages if my googling has just completely missed the target! > I do not have any news (good or bad) concerning RXTX and Sun working together but perhaps others here do. The main goal of RXTX is to expose POSIX termios interfaces to java users. The future support of javax.comm is questionable. We do not have resources for everything. gnu.io (RXTX 2.1) will be supported going forward and functions the same as CommAPI 2.0. If you have control of the source code you are working with, I would not advise using CommAPI 2.0 javax.comm. We do support CommAPI 2.0 javax.comm for older applications but I do not think that will last much longer for practical reasons. The download interest in CommAPI 2.0 javax.comm support is becomming negligible on this end. There has been discussion of a JSR effort but I do not know of any status change since it was mentioned. One problem with a JSR is that even a light weight process is going to be difficult for RXTX at this time. Maybe that will change in the future but then again it may not. For now, we are just going forward 'as is' in rxtx 2.1 with package gnu.io while trying as a secondary effort to backport the changes to rxtx 2.0 for javax.comm support for users that do not have a choice. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Mar 11 07:19:40 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 11 Mar 2007 08:19:40 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: Hi All, I have been a proponent of a JSR that makes use of RXTX. I have executed the proper agreements with Sun. At this point we are in the: Early Draft Review of Draft Specifications Stage. The best thing to do is to enter the quiet period and create a specification. The question of exactly how we, as a group, want to approach this problem, remains open. Typically, we should have both a specification and a reference implementation. Thus, it would be to our best advantage to have a nice, stable, cross platform RXTX distro that adheres to the groups specification. Now, from a specification standpoint, my personal view on the matter is that we create a series of interfaces, with nice documentation (or at least javadoc). Is this a good idea? Should we have a pure interface specification for the communication API? There are several issues, in my mind, which still weigh on us. Hot-pluggable dongles, long discovery process on pop-up ports, lack of uniformity on device names, lack of uniformity on locking, a precise understanding of how the SerialPortResourceManager works (or even if we should have one). The more questions we answer in our reference implementation, the better our specification will get. RXTX is a good working prototype, but, I don't know if that is what we want to use for a specification. Here is what I have for a CommPortInterface: */ public interface CommPortInterface { /** * @return a string representation of this port. */ String toString(); /** * Gets the name of the communications port. This name should correspond to * something the user can identify, like the label on the hardware. * @return name of the port */ String getName(); /** * @return an input stream that can be used to read data from the * communications port. If the port doesn't support reading data, this * method returns null. *

* The blocking behaviour of this input stream depends on the threshold * and timeout values, as shown below for a read buffer size of n * bytes: * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ThresholdTimeoutBlocking behaviour
StateValueStateValue
disableddisabledblock until data is available
enabledm bytesdisabledblock until min(m, n) bytes are available
disabledenabledt msblock for t ms or until data is available
enabledm bytesenabledt msblock for t ms or until min(m, n) bytes are * available
* @throws java.io.IOException */ InputStream getInputStream() throws IOException; /** * @return an output stream that can be used to send data to the * communications port. If the port doesn't support sending data, this * method returns null. * @throws java.io.IOException */ OutputStream getOutputStream() throws IOException; /** * Closes this communications port. * All PortOwnershipListeners will be? * notified of this change of ownership. Further method calls on this? * object will throw IllegalStateException. Further calls on the? * associated InputStream or OutputStream will throw IOException. *

* Close does not block. Undelivered data is discarded. Blocked read and? * write operations are aborted if the underlying operating systems? * supports an IO abort mechanism. To await the delivery of undelivered? * data call OutputStream.flush() or OutputStream.close() before calling? * Port.close(). */ void close(); /** * Enables receive threshold. * When the specified threshold number of bytes are retrieved, read will * return immediately. * * @param thresh the number of bytes in the input buffer * @throws gnu.io.UnsupportedCommOperationException * if receive threshold is * not supported by the driver * @see #disableReceiveThreshold */ void enableReceiveThreshold(int thresh) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive threshold. * * @see #enableReceiveThreshold */ void disableReceiveThreshold(); /** * @return true if receive threshold is enabled. * * @see #enableReceiveThreshold */ boolean isReceiveThresholdEnabled(); /** * @return the receive threshold value. If receive threshold is diabled * or not supported, this value is meaningless. * * @see #enableReceiveThreshold */ int getReceiveThreshold(); /** * Enables receive timeout. * When the specified number of milliseconds have elapsed, read will * return immediately. * * @param rcvTimeout the number of milliseconds to block for * @throws gnu.io.UnsupportedCommOperationException * if receive timeout is * not supported by the driver * @see #disableReceiveTimeout */ void enableReceiveTimeout(int rcvTimeout) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive timeout. * * @see #enableReceiveTimeout */ void disableReceiveTimeout(); /** * @return true if receive timeout is enabled. * * @see #enableReceiveTimeout */ boolean isReceiveTimeoutEnabled(); /** * @return the receive timeout value. If receive timeout is diabled * or not supported, this value is meaningless. * * @see #enableReceiveTimeout */ int getReceiveTimeout(); /** * Enables receive framing. * The supplied byte value in the input suggests the end of the received * frame, and read returns immediately. Only the low 8 bits of the * supplied value are significant. * * @param framingByte the frame delimiter * @throws gnu.io.UnsupportedCommOperationException * if receive framing is * not supported by the driver * @see #disableReceiveFraming */ void enableReceiveFraming(int framingByte) throws UnsupportedCommOperationException; /** * Disables receive framing. * * @see #enableReceiveFraming */ void disableReceiveFraming(); /** * @return true if receive framing is enabled. * * @see #enableReceiveFraming */ boolean isReceiveFramingEnabled(); /** * @return true if receive framing byte. If receive framing is diabled * or not supported, this value is meaningless. * * @see #enableReceiveFraming */ int getReceiveFramingByte(); /** * Sets the input buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setInputBufferSize(int size); /** * @return the input buffer size. * The driver may choose not to report correct values. */ int getInputBufferSize(); /** * Sets the output buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setOutputBufferSize(int size); /** * @return the output buffer size. * The driver may choose not to report correct values. */ int getOutputBufferSize(); } What do you think of that? Note the wishy washy nature of the spec: The driver may choose to ignore this method. Is that good enough for us? Thanks! - Doug From ra85551 at gmail.com Sun Mar 11 08:44:45 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Sun, 11 Mar 2007 17:44:45 +0300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hello, world! I am writing application that communicates with modem via AT commands. My OS is Linux Kubuntu Feisty Herd, to ensure that my application will run properly under Windows XP I installed VMWare server. When I tried to send AT command and evaluate modem answer under WinXP @ VMWare server, I actually didn't receive anything. I think that VM settings are right, because I do can communicate with modem by using standard HyperTerminall as well as I can do on native Windows. So, why RXTX doesn't work under VM, but works under Linux and pure Windows XP (i tested it there) well? The send/receive method code follows. private String sendATCommand(String command, final String waitFor, final boolean isRegex, boolean isAddCRLF, long timeout) throws BeaconConnectException { final long POLL_PERIOD = 100; final int BUFFER_SIZE = 512; final byte[] buffer = new byte[BUFFER_SIZE]; final InputStream serialInput; final OutputStream serialOutput; try { serialInput = serialPort.getInputStream(); if (command != null) { serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } } catch (IOException e) { throw new MyException("serial I/O error"); } TimerTask task = new TimerTask() { int offset = 0; int bytesRead; public synchronized void run() { try { if (serialInput.available() > 0) { bytesRead = serialInput.read(buffer, offset, BUFFER_SIZE - offset); } else { return; } } catch (IOException e) { // do nothing - maybe next time we'll read something } offset += bytesRead; if (waitFor != null) { String temporary = new String(buffer, 0, offset).trim(); if (isRegex && temporary.matches(waitFor) || temporary.contains(waitFor)) { cancel(); notify(); } } } }; Timer timer = new Timer(); timer.schedule(task, POLL_PERIOD, POLL_PERIOD); synchronized (task) { try { task.wait(timeout); task.cancel(); } catch (InterruptedException e) { } } //Cut off leading and trailing CRs, LFs and zeroes String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); System.out.println(response); return response; } -- Pavel Parkhomenko From tjarvi at qbang.org Sun Mar 11 11:48:22 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:48:22 -0600 (MDT) Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: On Sun, 11 Mar 2007, Pavel Parkhomenko wrote: > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. > > private String sendATCommand(String command, final String waitFor, > final boolean isRegex, boolean isAddCRLF, long timeout) > throws BeaconConnectException > { > final long POLL_PERIOD = 100; > final int BUFFER_SIZE = 512; > final byte[] buffer = new byte[BUFFER_SIZE]; > final InputStream serialInput; > final OutputStream serialOutput; > try > { > serialInput = serialPort.getInputStream(); > if (command != null) > { > serialOutput = serialPort.getOutputStream(); > if (isAddCRLF) > { > command += "\r\n"; > } > System.out.println(command); > serialOutput.write(command.getBytes()); > } > } > catch (IOException e) > { > throw new MyException("serial I/O error"); > } > > TimerTask task = new TimerTask() > { > int offset = 0; > int bytesRead; > public synchronized void run() > { > try > { > if (serialInput.available() > 0) > { > bytesRead = serialInput.read(buffer, offset, > BUFFER_SIZE - offset); > } > else > { > return; > } > } > catch (IOException e) > { > // do nothing - maybe next time we'll read something > } > offset += bytesRead; > if (waitFor != null) > { > String temporary = new String(buffer, 0, offset).trim(); > if (isRegex && temporary.matches(waitFor) || > temporary.contains(waitFor)) > { > cancel(); > notify(); > } > } > } > }; > > Timer timer = new Timer(); > timer.schedule(task, POLL_PERIOD, POLL_PERIOD); > synchronized (task) { > try > { > task.wait(timeout); > task.cancel(); > } > catch (InterruptedException e) > { > } > } > //Cut off leading and trailing CRs, LFs and zeroes > String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); > System.out.println(response); > return response; > } > > > Hi Pavel VMWare should not be a problem. I've used it in the past - though not with a modem. Make sure nothing else is using the modem. Then look in the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an example that should work. Note that modems could care less what OS is on top. If you are trying to match new lines to the OS and sending it to the mode for AT commands, thats probably a mistake. Also it would not hurt to print out the individual bytes that you are sending to make sure they did not get mangled along the path. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 11:55:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:55:48 -0600 (MDT) Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: On Sun, 11 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > I have been a proponent of a JSR that makes > use of RXTX. I have executed the proper agreements with Sun. > > At this point we are in the: > Early Draft Review of Draft Specifications Stage. > > The best thing to do is to enter the quiet period and create > a specification. The question of exactly how we, as a group, > want to approach this problem, remains open. > > Typically, we should have both a specification and a reference > implementation. Thus, it would be to our best advantage to have > a nice, stable, cross platform RXTX distro that adheres to the > groups specification. > > Now, from a specification standpoint, my personal view on the matter is > that we create a series of interfaces, with nice documentation (or at least > javadoc). > > Is this a good idea? Should we have a pure interface specification for > the communication API? > > There are several issues, in my mind, which still weigh on us. > Hot-pluggable dongles, long discovery process on pop-up ports, > lack of uniformity on device names, lack of uniformity on locking, > a precise understanding of how the SerialPortResourceManager > works (or even if we should have one). > > The more questions we answer in our reference implementation, the > better our specification will get. RXTX is a good working prototype, > but, I don't know if that is what we want to use for a specification. > > Here is what I have for a CommPortInterface: > */ > public interface CommPortInterface { Hi Doug, I can start going through the method interfaces later this week and giving feedback. I would suggest that the JSR should not be too generic in nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel drivers that intend to look like EIA232 ports at the kernel driver level. some ideas: EIA232PortInterface TermiosInterface SerialPortInterface Something that differentiates this from thing like USB, I2C, ... which should not have to deal with legacy serial claiming to be the comm api. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 12:52:19 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 12:52:19 -0600 (MDT) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: No news is good news with these posts. I'll start the process of pinging legal a week from Monday on my end if nobody has objections to the proposal. I just want to make sure everyone has time to raise objections. Obviously, anyone can fork from a previous version if they don't like the new license. I suspect we can avoid that though. On Sun, 4 Mar 2007, Trent Jarvi wrote: > > For those that are wondering what is going on here, this > next bit is the meat of the changes. We agreed a long time > ago to put this disclaimer in. We did a so so job. It was > in rxtx 2.0, not well written, ... So some groups using > rxtx that would like to ship rxtx so users don't need to > download, install, go to the mail-list to find why it failed, > ... Then their legal teams tell them section 5 paragraph 2 > is a show stopper. > > That was never the intent. > > > Now going through what remains... > >> and might need a (TM) suffix to make Sun happy. > > Added disclaimer at the ended 'all trademarks belong...' > >> * Line #15ff - static vs. dynamic linking - you did >> not transcribe the text from the "controlled >> interface exception" when writing this text - and >> this was good so, because these terms originally >> refer to the GPL rather than the LGPL. I think though, >> that these 4 lines are the most important ones and >> should thus be really really clear. I hope that I >> meet your original intent with the following >> suggestions: >> 1.) Instead of "A program.." it would be better to >> say "An exectuable.." in order to be closer to >> the LGPL text. > > OK. As you can see I was trying to adjust GNU text there > for the LGPL. > >> 2.) It would be better to say .. "by being dynamically >> linked with it" to clearly indicate that dynamic >> linking is meant. The matter of compilation is >> already covered by the LGPL so mentioning it again >> just leads to confusion. > > used dynamically linked terminology. > >> 3.) It would be better to say .. "is considered a >> work that uses the library in contrast to section >> 5 of the LGPL, so the terms of the LGPL do not >> apply to the resulting executable". > > I tried to address this more upfront with an intent statement. > Let me know if you have problems with it. I also tried to > make it a little more clear what was derived from the GNU > solution by moving the link location closer to GNU's suggestion. > >> >> Note that LGPL section 5 says: ..."is called a >> "work that uses the Library". Such a work, in isolation, >> is not a derivative work of the Library, and therefore >> falls outside the scope of this License." >> The next paragraph of the LGPL is exactly the problematic >> one that I hope is clarified by the exception terms you >> give. >> > > Thats the intent. Here is the combined fixes. Note that only the > material in /*-- --*/ is being touched. The new GPL license is > there but unmodified. > > > ------------------------ begin proposed new license ------------------- > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Lesser General Public > | License as published by the Free Software Foundation; either > | version 2.1 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Lesser General Public License for more details. > | > | An executable that contains no derivative of any portion of RXTX, but > | is designed to work with RXTX by being dynamically linked with it, > | is considered a "work that uses the Library" subject to the terms and > | conditions of the GNU Lesser General Public License. > | > | The following has been added to the RXTX License to remove > | any confusion about linking to RXTX. We want to allow in part what > | section 5, paragraph 2 of the LGPL does not permit in the special > | case of linking over a controlled interface. The intent is to add a > | Java Specification Request or standards body defined interface in the > | future as another exception but one is not currently available. > | > | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface > | > | As a special exception, the copyright holders of RXTX give you > | permission to link RXTX with independent modules that communicate with > | RXTX solely through the Sun Microsytems CommAPI interface version 2, > | regardless of the license terms of these independent modules, and to copy > | and distribute the resulting combined work under terms of your choice, > | provided that every copy of the combined work is accompanied by a complete > | copy of the source code of RXTX (the version of RXTX used to produce the > | combined work), being distributed under the terms of the GNU Lesser General > | Public License plus this exception. An independent module is a > | module which is not derived from or based on RXTX. > | > | Note that people who make modified versions of RXTX are not obligated > | to grant this special exception for their modified versions; it is > | their choice whether to do so. The GNU Lesser General Public License > | gives permission to release a modified version without this exception; this > | exception also makes it possible to release a modified version which > | carries forward this exception. > | > | You should have received a copy of the GNU Lesser General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > | All trademarks belong to their respective owners. > --------------------------------------------------------------------------*/ > > The original GNU Lesser General Public License Follows. > > > GNU LESSER GENERAL PUBLIC LICENSE > Version 2.1, February 1999 > > Copyright (C) 1991, 1999 Free Software Foundation, Inc. > 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > Everyone is permitted to copy and distribute verbatim copies > of this license document, but changing it is not allowed. > > [This is the first released version of the Lesser GPL. It also counts > as the successor of the GNU Library Public License, version 2, hence > the version number 2.1.] > > Preamble > > The licenses for most software are designed to take away your > freedom to share and change it. By contrast, the GNU General Public > Licenses are intended to guarantee your freedom to share and change > free software--to make sure the software is free for all its users. > > This license, the Lesser General Public License, applies to some > specially designated software packages--typically libraries--of the > Free Software Foundation and other authors who decide to use it. You > can use it too, but we suggest you first think carefully about whether > this license or the ordinary General Public License is the better > strategy to use in any particular case, based on the explanations below. > > When we speak of free software, we are referring to freedom of use, > not price. Our General Public Licenses are designed to make sure that > you have the freedom to distribute copies of free software (and charge > for this service if you wish); that you receive source code or can get > it if you want it; that you can change the software and use pieces of > it in new free programs; and that you are informed that you can do > these things. > > To protect your rights, we need to make restrictions that forbid > distributors to deny you these rights or to ask you to surrender these > rights. These restrictions translate to certain responsibilities for > you if you distribute copies of the library or if you modify it. > > For example, if you distribute copies of the library, whether gratis > or for a fee, you must give the recipients all the rights that we gave > you. You must make sure that they, too, receive or can get the source > code. If you link other code with the library, you must provide > complete object files to the recipients, so that they can relink them > with the library after making changes to the library and recompiling > it. And you must show them these terms so they know their rights. > > We protect your rights with a two-step method: (1) we copyright the > library, and (2) we offer you this license, which gives you legal > permission to copy, distribute and/or modify the library. > > To protect each distributor, we want to make it very clear that > there is no warranty for the free library. Also, if the library is > modified by someone else and passed on, the recipients should know > that what they have is not the original version, so that the original > author's reputation will not be affected by problems that might be > introduced by others. > > Finally, software patents pose a constant threat to the existence of > any free program. We wish to make sure that a company cannot > effectively restrict the users of a free program by obtaining a > restrictive license from a patent holder. Therefore, we insist that > any patent license obtained for a version of the library must be > consistent with the full freedom of use specified in this license. > > Most GNU software, including some libraries, is covered by the > ordinary GNU General Public License. This license, the GNU Lesser > General Public License, applies to certain designated libraries, and > is quite different from the ordinary General Public License. We use > this license for certain libraries in order to permit linking those > libraries into non-free programs. > > When a program is linked with a library, whether statically or using > a shared library, the combination of the two is legally speaking a > combined work, a derivative of the original library. The ordinary > General Public License therefore permits such linking only if the > entire combination fits its criteria of freedom. The Lesser General > Public License permits more lax criteria for linking other code with > the library. > > We call this license the "Lesser" General Public License because it > does Less to protect the user's freedom than the ordinary General > Public License. It also provides other free software developers Less > of an advantage over competing non-free programs. These disadvantages > are the reason we use the ordinary General Public License for many > libraries. However, the Lesser license provides advantages in certain > special circumstances. > > For example, on rare occasions, there may be a special need to > encourage the widest possible use of a certain library, so that it becomes > a de-facto standard. To achieve this, non-free programs must be > allowed to use the library. A more frequent case is that a free > library does the same job as widely used non-free libraries. In this > case, there is little to gain by limiting the free library to free > software only, so we use the Lesser General Public License. > > In other cases, permission to use a particular library in non-free > programs enables a greater number of people to use a large body of > free software. For example, permission to use the GNU C Library in > non-free programs enables many more people to use the whole GNU > operating system, as well as its variant, the GNU/Linux operating > system. > > Although the Lesser General Public License is Less protective of the > users' freedom, it does ensure that the user of a program that is > linked with the Library has the freedom and the wherewithal to run > that program using a modified version of the Library. > > The precise terms and conditions for copying, distribution and > modification follow. Pay close attention to the difference between a > "work based on the library" and a "work that uses the library". The > former contains code derived from the library, whereas the latter must > be combined with the library in order to run. > > GNU LESSER GENERAL PUBLIC LICENSE > TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION > > 0. This License Agreement applies to any software library or other > program which contains a notice placed by the copyright holder or > other authorized party saying it may be distributed under the terms of > this Lesser General Public License (also called "this License"). > Each licensee is addressed as "you". > > A "library" means a collection of software functions and/or data > prepared so as to be conveniently linked with application programs > (which use some of those functions and data) to form executables. > > The "Library", below, refers to any such software library or work > which has been distributed under these terms. A "work based on the > Library" means either the Library or any derivative work under > copyright law: that is to say, a work containing the Library or a > portion of it, either verbatim or with modifications and/or translated > straightforwardly into another language. (Hereinafter, translation is > included without limitation in the term "modification".) > > "Source code" for a work means the preferred form of the work for > making modifications to it. For a library, complete source code means > all the source code for all modules it contains, plus any associated > interface definition files, plus the scripts used to control compilation > and installation of the library. > > Activities other than copying, distribution and modification are not > covered by this License; they are outside its scope. The act of > running a program using the Library is not restricted, and output from > such a program is covered only if its contents constitute a work based > on the Library (independent of the use of the Library in a tool for > writing it). Whether that is true depends on what the Library does > and what the program that uses the Library does. > > 1. You may copy and distribute verbatim copies of the Library's > complete source code as you receive it, in any medium, provided that > you conspicuously and appropriately publish on each copy an > appropriate copyright notice and disclaimer of warranty; keep intact > all the notices that refer to this License and to the absence of any > warranty; and distribute a copy of this License along with the > Library. > > You may charge a fee for the physical act of transferring a copy, > and you may at your option offer warranty protection in exchange for a > fee. > > 2. You may modify your copy or copies of the Library or any portion > of it, thus forming a work based on the Library, and copy and > distribute such modifications or work under the terms of Section 1 > above, provided that you also meet all of these conditions: > > a) The modified work must itself be a software library. > > b) You must cause the files modified to carry prominent notices > stating that you changed the files and the date of any change. > > c) You must cause the whole of the work to be licensed at no > charge to all third parties under the terms of this License. > > d) If a facility in the modified Library refers to a function or a > table of data to be supplied by an application program that uses > the facility, other than as an argument passed when the facility > is invoked, then you must make a good faith effort to ensure that, > in the event an application does not supply such function or > table, the facility still operates, and performs whatever part of > its purpose remains meaningful. > > (For example, a function in a library to compute square roots has > a purpose that is entirely well-defined independent of the > application. Therefore, Subsection 2d requires that any > application-supplied function or table used by this function must > be optional: if the application does not supply it, the square > root function must still compute square roots.) > > These requirements apply to the modified work as a whole. If > identifiable sections of that work are not derived from the Library, > and can be reasonably considered independent and separate works in > themselves, then this License, and its terms, do not apply to those > sections when you distribute them as separate works. But when you > distribute the same sections as part of a whole which is a work based > on the Library, the distribution of the whole must be on the terms of > this License, whose permissions for other licensees extend to the > entire whole, and thus to each and every part regardless of who wrote > it. > > Thus, it is not the intent of this section to claim rights or contest > your rights to work written entirely by you; rather, the intent is to > exercise the right to control the distribution of derivative or > collective works based on the Library. > > In addition, mere aggregation of another work not based on the Library > with the Library (or with a work based on the Library) on a volume of > a storage or distribution medium does not bring the other work under > the scope of this License. > > 3. You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. To do > this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version 2, > instead of to this License. (If a newer version than version 2 of the > ordinary GNU General Public License has appeared, then you can specify > that version instead if you wish.) Do not make any other change in > these notices. > > Once this change is made in a given copy, it is irreversible for > that copy, so the ordinary GNU General Public License applies to all > subsequent copies and derivative works made from that copy. > > This option is useful when you wish to copy part of the code of > the Library into a program that is not a library. > > 4. You may copy and distribute the Library (or a portion or > derivative of it, under Section 2) in object code or executable form > under the terms of Sections 1 and 2 above provided that you accompany > it with the complete corresponding machine-readable source code, which > must be distributed under the terms of Sections 1 and 2 above on a > medium customarily used for software interchange. > > If distribution of object code is made by offering access to copy > from a designated place, then offering equivalent access to copy the > source code from the same place satisfies the requirement to > distribute the source code, even though third parties are not > compelled to copy the source along with the object code. > > 5. A program that contains no derivative of any portion of the > Library, but is designed to work with the Library by being compiled or > linked with it, is called a "work that uses the Library". Such a > work, in isolation, is not a derivative work of the Library, and > therefore falls outside the scope of this License. > > However, linking a "work that uses the Library" with the Library > creates an executable that is a derivative of the Library (because it > contains portions of the Library), rather than a "work that uses the > library". The executable is therefore covered by this License. > Section 6 states terms for distribution of such executables. > > When a "work that uses the Library" uses material from a header file > that is part of the Library, the object code for the work may be a > derivative work of the Library even though the source code is not. > Whether this is true is especially significant if the work can be > linked without the Library, or if the work is itself a library. The > threshold for this to be true is not precisely defined by law. > > If such an object file uses only numerical parameters, data > structure layouts and accessors, and small macros and small inline > functions (ten lines or less in length), then the use of the object > file is unrestricted, regardless of whether it is legally a derivative > work. (Executables containing this object code plus portions of the > Library will still fall under Section 6.) > > Otherwise, if the work is a derivative of the Library, you may > distribute the object code for the work under the terms of Section 6. > Any executables containing that work also fall under Section 6, > whether or not they are linked directly with the Library itself. > > 6. As an exception to the Sections above, you may also combine or > link a "work that uses the Library" with the Library to produce a > work containing portions of the Library, and distribute that work > under terms of your choice, provided that the terms permit > modification of the work for the customer's own use and reverse > engineering for debugging such modifications. > > You must give prominent notice with each copy of the work that the > Library is used in it and that the Library and its use are covered by > this License. You must supply a copy of this License. If the work > during execution displays copyright notices, you must include the > copyright notice for the Library among them, as well as a reference > directing the user to the copy of this License. Also, you must do one > of these things: > > a) Accompany the work with the complete corresponding > machine-readable source code for the Library including whatever > changes were used in the work (which must be distributed under > Sections 1 and 2 above); and, if the work is an executable linked > with the Library, with the complete machine-readable "work that > uses the Library", as object code and/or source code, so that the > user can modify the Library and then relink to produce a modified > executable containing the modified Library. (It is understood > that the user who changes the contents of definitions files in the > Library will not necessarily be able to recompile the application > to use the modified definitions.) > > b) Use a suitable shared library mechanism for linking with the > Library. A suitable mechanism is one that (1) uses at run time a > copy of the library already present on the user's computer system, > rather than copying library functions into the executable, and (2) > will operate properly with a modified version of the library, if > the user installs one, as long as the modified version is > interface-compatible with the version that the work was made with. > > c) Accompany the work with a written offer, valid for at > least three years, to give the same user the materials > specified in Subsection 6a, above, for a charge no more > than the cost of performing this distribution. > > d) If distribution of the work is made by offering access to copy > from a designated place, offer equivalent access to copy the above > specified materials from the same place. > > e) Verify that the user has already received a copy of these > materials or that you have already sent this user a copy. > > For an executable, the required form of the "work that uses the > Library" must include any data and utility programs needed for > reproducing the executable from it. However, as a special exception, > the materials to be distributed need not include anything that is > normally distributed (in either source or binary form) with the major > components (compiler, kernel, and so on) of the operating system on > which the executable runs, unless that component itself accompanies > the executable. > > It may happen that this requirement contradicts the license > restrictions of other proprietary libraries that do not normally > accompany the operating system. Such a contradiction means you cannot > use both them and the Library together in an executable that you > distribute. > > 7. You may place library facilities that are a work based on the > Library side-by-side in a single library together with other library > facilities not covered by this License, and distribute such a combined > library, provided that the separate distribution of the work based on > the Library and of the other library facilities is otherwise > permitted, and provided that you do these two things: > > a) Accompany the combined library with a copy of the same work > based on the Library, uncombined with any other library > facilities. This must be distributed under the terms of the > Sections above. > > b) Give prominent notice with the combined library of the fact > that part of it is a work based on the Library, and explaining > where to find the accompanying uncombined form of the same work. > > 8. You may not copy, modify, sublicense, link with, or distribute > the Library except as expressly provided under this License. Any > attempt otherwise to copy, modify, sublicense, link with, or > distribute the Library is void, and will automatically terminate your > rights under this License. However, parties who have received copies, > or rights, from you under this License will not have their licenses > terminated so long as such parties remain in full compliance. > > 9. You are not required to accept this License, since you have not > signed it. However, nothing else grants you permission to modify or > distribute the Library or its derivative works. These actions are > prohibited by law if you do not accept this License. Therefore, by > modifying or distributing the Library (or any work based on the > Library), you indicate your acceptance of this License to do so, and > all its terms and conditions for copying, distributing or modifying > the Library or works based on it. > > 10. Each time you redistribute the Library (or any work based on the > Library), the recipient automatically receives a license from the > original licensor to copy, distribute, link with or modify the Library > subject to these terms and conditions. You may not impose any further > restrictions on the recipients' exercise of the rights granted herein. > You are not responsible for enforcing compliance by third parties with > this License. > > 11. If, as a consequence of a court judgment or allegation of patent > infringement or for any other reason (not limited to patent issues), > conditions are imposed on you (whether by court order, agreement or > otherwise) that contradict the conditions of this License, they do not > excuse you from the conditions of this License. If you cannot > distribute so as to satisfy simultaneously your obligations under this > License and any other pertinent obligations, then as a consequence you > may not distribute the Library at all. For example, if a patent > license would not permit royalty-free redistribution of the Library by > all those who receive copies directly or indirectly through you, then > the only way you could satisfy both it and this License would be to > refrain entirely from distribution of the Library. > > If any portion of this section is held invalid or unenforceable under any > particular circumstance, the balance of the section is intended to apply, > and the section as a whole is intended to apply in other circumstances. > > It is not the purpose of this section to induce you to infringe any > patents or other property right claims or to contest validity of any > such claims; this section has the sole purpose of protecting the > integrity of the free software distribution system which is > implemented by public license practices. Many people have made > generous contributions to the wide range of software distributed > through that system in reliance on consistent application of that > system; it is up to the author/donor to decide if he or she is willing > to distribute software through any other system and a licensee cannot > impose that choice. > > This section is intended to make thoroughly clear what is believed to > be a consequence of the rest of this License. > > 12. If the distribution and/or use of the Library is restricted in > certain countries either by patents or by copyrighted interfaces, the > original copyright holder who places the Library under this License may add > an explicit geographical distribution limitation excluding those countries, > so that distribution is permitted only in or among countries not thus > excluded. In such case, this License incorporates the limitation as if > written in the body of this License. > > 13. The Free Software Foundation may publish revised and/or new > versions of the Lesser General Public License from time to time. > Such new versions will be similar in spirit to the present version, > but may differ in detail to address new problems or concerns. > > Each version is given a distinguishing version number. If the Library > specifies a version number of this License which applies to it and > "any later version", you have the option of following the terms and > conditions either of that version or of any later version published by > the Free Software Foundation. If the Library does not specify a > license version number, you may choose any version ever published by > the Free Software Foundation. > > 14. If you wish to incorporate parts of the Library into other free > programs whose distribution conditions are incompatible with these, > write to the author to ask for permission. For software which is > copyrighted by the Free Software Foundation, write to the Free > Software Foundation; we sometimes make exceptions for this. Our > decision will be guided by the two goals of preserving the free status > of all derivatives of our free software and of promoting the sharing > and reuse of software generally. > > NO WARRANTY > > 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO > WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. > EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR > OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY > KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE > IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE > LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME > THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. > > 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN > WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY > AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU > FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR > CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE > LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING > RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A > FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF > SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH > DAMAGES. > > END OF TERMS AND CONDITIONS > > How to Apply These Terms to Your New Libraries > > If you develop a new library, and you want it to be of the greatest > possible use to the public, we recommend making it free software that > everyone can redistribute and change. You can do so by permitting > redistribution under these terms (or, alternatively, under the terms of the > ordinary General Public License). > > To apply these terms, attach the following notices to the library. It is > safest to attach them to the start of each source file to most effectively > convey the exclusion of warranty; and each file should have at least the > "copyright" line and a pointer to where the full notice is found. > > > Copyright (C) > > This library is free software; you can redistribute it and/or > modify it under the terms of the GNU Lesser General Public > License as published by the Free Software Foundation; either > version 2.1 of the License, or (at your option) any later version. > > This library is distributed in the hope that it will be useful, > but WITHOUT ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > Lesser General Public License for more details. > > You should have received a copy of the GNU Lesser General Public > License along with this library; if not, write to the Free Software > Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > > Also add information on how to contact you by electronic and paper mail. > > You should also get your employer (if you work as a programmer) or your > school, if any, to sign a "copyright disclaimer" for the library, if > necessary. Here is a sample; alter the names: > > Yoyodyne, Inc., hereby disclaims all copyright interest in the > library `Frob' (a library for tweaking knobs) written by James Random Hacker. > > , 1 April 1990 > Ty Coon, President of Vice > > That's all there is to it! > ------------------------ end of proposed license ------------------ > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From gjhanna at gmail.com Sun Mar 11 14:21:17 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Mon, 12 Mar 2007 09:21:17 +1300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hi Pavel, We are using RXTX under VMWare server in production, quite satisfactorily. We're using Red Hat Enterprise Server 4, and ... Whatever the "enterprise" VMWare product is. Regards, Greg H > Subject: [Rxtx] RXTX under VMWare server > To: rxtx at qbang.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. [ ... snip ... ] -- Pavel Parkhomenko -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070311/4cebb6f9/attachment-0082.html From gergg at cox.net Sun Mar 11 23:39:19 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 12 Mar 2007 00:39:19 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: <45F4E787.6050502@cox.net> Trent Jarvi wrote: > I can start going through the method interfaces later this week and giving > feedback. I would suggest that the JSR should not be too generic in > nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel > drivers that intend to look like EIA232 ports at the kernel driver level. > > some ideas: > > EIA232PortInterface > TermiosInterface > SerialPortInterface > > Something that differentiates this from thing like USB, I2C, ... which > should not have to deal with legacy serial claiming to be the comm api. I'm going to throw out a suggestion, which I am mostly serious about. What would happen if we took the appropriate bits of the J2ME connector API, and just used that as the new COMM API so that finally JSE and JME had a common foundation for these kinds of things? Gregg Wonderly From ra85551 at gmail.com Mon Mar 12 09:08:37 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Mon, 12 Mar 2007 18:08:37 +0300 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Should any application use the modem, HyperTerminal won't be able to talk to the modem. But it actually can send and receive AT comands, while my application cannot :-( > Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Thansk for the reference. I examined that example and found that there's no significant differences between my read/write implementation and that one, except that SimpleSnuV1 listens for serialEvent's, but not for sake of data retrieval, just for printing them out - I don't know why ;-) > Note that modems could care less what OS is on top. If you are trying to > match new lines to the OS and sending it to the mode for AT commands, > thats probably a mistake. I do send strings to serial port, not to OS, and do try to get answers back. If it is the mistake, what's the right way? > Also it would not hurt to print out the > individual bytes that you are sending to make sure they did not get > mangled along the path. Yeah, I am printing these bytes before doing write, but it means that I only see what I intend to write. How can I ensure that these bytes have gone out of the box and reached my modem? BTW, I found that my send/receive method is complex enough, so I've rewritten it. Please, see the following code and point any mistakes, because I don't know where can they remain yet. private static final int LARGE_TIMEOUT = 15000; private static final int SMALL_TIMEOUT = 500; ... private String sendATCommand(String command, String waitFor, boolean isRegex, boolean isAddCRLF) throws BeaconConnectException { byte[] buffer = new byte[512]; int offset; String result = ""; try { if (waitFor != null) { serialPort.enableReceiveTimeout(LARGE_TIMEOUT); } else { serialPort.enableReceiveTimeout(SMALL_TIMEOUT); } if (command != null) { OutputStream serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } offset = 0; InputStream serialInput = serialPort.getInputStream(); while (serialInput.available() != -1) { int bytesRead = serialInput.read(buffer, offset, buffer.length - offset); if (bytesRead == 0) { break; } offset += bytesRead; result = new String(buffer, 0, offset).trim(); if (waitFor != null) { System.out.println(result); if (isRegex && result.matches(waitFor) || result.contains(waitFor)) { break; } } } } catch (UnsupportedCommOperationException e) { throw new MyException("unsupported operation"); } catch (IOException e) { throw new MytException("serial I/O error"); } return result; } -- Pavel Parkhomenko From clayno at hotpop.com Thu Mar 15 02:47:34 2007 From: clayno at hotpop.com (Christopher Layno) Date: Thu, 15 Mar 2007 16:47:34 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi, we're using the latest release of rxtx (2.1-7r2) for our system that has two applications using the library. one application sends requests to the modem while the other simply checks the modem status. we deployed our system on a pentium machine with red hat linux 9.0 installed. now the problem arises when these two applications try to access the same modem at the same time. one of them will eventually have to throw the PortInUseException as shown below: 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException gnu.io.PortInUseException: root PID = 743 Program = java root PID = 743 Program = java root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) this was expected. what we didn't expect though was that if we repeat the scenario 5 times, always 5 times, the application would also throw a VM error: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4473CD21 Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so Current Java thread: at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) - locked <0x44cfd4c8> (a gnu.io.CommPortIdentifier) at ************ at ************ - locked <0x4476a468> (a **********) at ************ at ************ at ************ at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java :261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages( TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run( TCPTransport.java:701) at java.lang.Thread.run(Thread.java:534) note: i replaced some sensitive data with asterisks our team has looked everywhere on the internet, including your mail archives, for a solution to this problem but to no avail. i really hope you could help us out on this one. thanks in advance! best regards, chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070315/1936460a/attachment-0079.html From tjarvi at qbang.org Fri Mar 16 04:30:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 04:30:25 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: On Thu, 15 Mar 2007, Christopher Layno wrote: > hi, > > we're using the latest release of rxtx (2.1-7r2) for our system that has two > applications using the library. one application sends requests to the modem > while the other simply checks the modem status. we deployed our system on a > pentium machine with red hat linux 9.0 installed. > > now the problem arises when these two applications try to access the same > modem at the same time. one of them will eventually have to throw the > PortInUseException as shown below: > > 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException > gnu.io.PortInUseException: root PID = 743 Program = java root PID = > 743 Program = java root PID = 743 Program = ??? root PID = 743 Program > = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root > PID = 743 Program = ??? root PID = 743 Program = ??? > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > > this was expected. what we didn't expect though was that if we repeat the > scenario 5 times, always 5 times, the application would also throw a VM > error: > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x4473CD21 > Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 > Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so > > Current Java thread: > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) Hi Chris The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. The code is originally by Werner Almesberger. He gave us permission to use it in rxtx. You might look at what has changed since 1998 in his fuser application. Or you can just do like other OSs and do the following in fuserImp.c JNIEXPORT jstring JNICALL Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv *env, jobject obj, jstring arg) { return (*env)->NewStringUTF(env, "Unknown Application"); } It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. -- Trent Jarvi tjarvi at qang.org From Adrien.TOS at ingenico.com Fri Mar 16 05:11:12 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Fri, 16 Mar 2007 12:11:12 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903CBC312@frsnprexc1.usr.ingenico.loc> Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070316/972ab214/attachment-0078.html From joachim at buechse.de Fri Mar 16 05:13:24 2007 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 16 Mar 2007 12:13:24 +0100 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. From tjarvi at qbang.org Fri Mar 16 16:36:29 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 16:36:29 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Fri Mar 16 16:02:23 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 16 Mar 2007 18:02:23 -0400 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Not all platforms are Unix based. Also mixing native library usage and command-line calls is not an elegant solution, IMHO. One or the other, but not both. Andre On 16-Mar-07, at 07:13 , Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is > trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We >> only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From clayno at hotpop.com Sun Mar 18 22:17:28 2007 From: clayno at hotpop.com (Christopher Layno) Date: Mon, 19 Mar 2007 12:17:28 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi everyone, thank you so much for your replies. they were really helpful. anyway, before i sent the email, my team was already implementing a temporary solution by using joachim's suggestion. we invoked a lsof command from our java code although i share the same concern with trent and andre-john about portability issues. that's why i said it's just temporary. my superiors have yet to approve our bug fix. so my question now is this: is recompiling the rxtx source code the only way to solve this problem? because if it's the only solution, then i think my superiors would rather have a new release from the rxtx community itself that fixes this bug(?) rather than have my team recompile the source code. best regards, chris Trent Jarvi wrote: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. ... It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070318/237463b2/attachment-0075.html From tjarvi at qbang.org Mon Mar 19 16:20:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Mar 2007 16:20:52 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: Hi Chris I can compile a new version after the 21st if you do not feel comfortable doing so. Please send me an email reminder off-line then. On Mon, 19 Mar 2007, Christopher Layno wrote: > hi everyone, > > thank you so much for your replies. they were really helpful. > > anyway, before i sent the email, my team was already implementing a > temporary solution by using joachim's suggestion. > we invoked a lsof command from our java code although i share the same > concern with trent and andre-john about > portability issues. that's why i said it's just temporary. my superiors have > yet to approve our bug fix. > > so my question now is this: is recompiling the rxtx source code the only way > to solve this problem? because if it's the only > solution, then i think my superiors would rather have a new release from the > rxtx community itself that fixes this bug(?) > rather than have my team recompile the source code. > > best regards, > > chris > > Trent Jarvi wrote: > > Hi Joachim > > It would be nice to have that functionality but calling the program > introduces too many issues imho. Explaining to someone why rxtx invoked a > rogue lsof does not sound very interesting. > > On Fri, 16 Mar 2007, Joachim Buechse wrote: > > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: > > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. > > _______________________________________________ > Rxtx mailing list > Rxtx 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 Eric.Arseneau at sun.com Tue Mar 20 11:47:33 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Tue, 20 Mar 2007 10:47:33 -0700 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 Message-ID: <46001E35.9040608@sun.com> Anyone have any experience with RXTX working with JDK 6 on other platforms ? From mm at UDel.Edu Tue Mar 20 12:18:29 2007 From: mm at UDel.Edu (Mike Markowski) Date: Tue, 20 Mar 2007 14:18:29 -0400 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 In-Reply-To: <46001E35.9040608@sun.com> References: <46001E35.9040608@sun.com> Message-ID: <46002575.4000306@udel.edu> Eric Arseneau wrote: > Anyone have any experience with RXTX working with JDK 6 on other platforms ? I'm using 32 bit intel, gentoo linux, jdk6 with no problems. My applications only use a serial port, though, nothing on the parallel port. Mike From falko.guderian at gmx.de Wed Mar 21 08:17:35 2007 From: falko.guderian at gmx.de (Falko Guderian) Date: Wed, 21 Mar 2007 15:17:35 +0100 Subject: [Rxtx] RXTX binaries for SH4 Message-ID: <46013E7F.40102@gmx.de> Dear developers, I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no possiblities to compile the source code. Better, I'm not able to do this at the moment. Can you provide me with rxtxSerial.dll (SH4) in the rxtx-2.1-8-testing version? (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) The reason for the testing version is I need custom baud rates. Thanks for help. Kind regards, Falko Guderian From tjarvi at qbang.org Wed Mar 21 21:38:37 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Mar 2007 21:38:37 -0600 (MDT) Subject: [Rxtx] RXTX binaries for SH4 In-Reply-To: <46013E7F.40102@gmx.de> References: <46013E7F.40102@gmx.de> Message-ID: On Wed, 21 Mar 2007, Falko Guderian wrote: > Dear developers, > > I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no > possiblities to compile the source code. Better, I'm not able to do this > at the moment. Can you provide me with rxtxSerial.dll (SH4) in the > rxtx-2.1-8-testing version? > (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) > > The reason for the testing version is I need custom baud rates. > > Thanks for help. > Hi Falko WinCE binary format is not supported by gcc. That makes compiling limited to those familiar with the WinCE tools. I hope someone is able to provide them for you but it is not likely. WinCE has been compiled by others in the past but rxtx.org builds have never included WinCE. There is some information with the source concerning WinCE builds if you decide to do it. We can share your results too if you like. The source in the WinCE has never been updated for the custom baud rate. That would need changes from the main source I presume. If you look at the source, you will note that Michal Hobot created a mini fork in the source to handle wince but it has not been updated for 3 years. -- Trent Jarvi tjarvi at qbang.org From Adrien.TOS at ingenico.com Thu Mar 22 07:08:55 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Thu, 22 Mar 2007 14:08:55 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Hi everybody, Do you have any comments on this issue? Thanks! AT ________________________________ De : Adrien TOS Envoy? : vendredi 16 mars 2007 12:11 ? : 'rxtx at qbang.org' Cc : Adrien TOS Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070322/2306c538/attachment-0071.html From jeremy.reeve at zen.co.uk Mon Mar 19 07:36:04 2007 From: jeremy.reeve at zen.co.uk (Jeremy S. Reeve) Date: Mon, 19 Mar 2007 13:36:04 +0000 Subject: [Rxtx] rxtx failing to compile on Fedora Core 6 Message-ID: <1174311364.21865.6.camel@d9thc> When trying to compile latest source : rxtx-2.1-7r2 I get the following when running configure: ---------------- checking os.version 2.6.18-1.2200.fc5smp WARNING: configure is having a hard time determining which directory contains the file jni_md.h. Edit Makefile and fix the variable JAVANATINC to point to the correct directory. The following options are available: /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/ /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/linux/ If there are more than one option available the first was selected. WARNING: Kernel include files do not match the current kernel configure: creating ./config.status ------------------------ which seems OK checking the resultant Makefile but when attempting to build with gmake install I get the following output : ---------------------- 34 problems (34 warnings)/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/javah -classpath .:/home/jsr/rxtxsrc/rxtx-2.1-7r2:/home/jsr/rxtxsrc/rxtx-2.1-7r2/src:/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/ext/RXTXcomm.jar -d i686-pc-linux-gnu -jni `(for i in CommDriver CommPortEnumerator CommPortIdentifier CommPort CommPortOwnershipListener Configure I2C I2CPortEvent I2CPortEventListener I2CPort LPRPort NoSuchPortException ParallelPortEvent ParallelPortEventListener ParallelPort PortInUseException Raw RawPortEvent RawPortEventListener RawPort RS485 RS485PortEvent RS485PortEventListener RS485Port RXTXCommDriver RXTXPort RXTXVersion SerialPortEvent SerialPortEventListener SerialPort UnsupportedCommOperationException UnSupportedLoggerException Zystem;do \ if grep > /dev/null native.* \( /home/jsr/rxtxsrc/rxtx-2.1-7r2/./src/$i.java; then \ echo gnu.io.$i; \ fi; \ done)` i686-pc-linux-gnu/gnu_io_CommPortIdentifier.h: No such file or directory make: *** [/home/jsr/rxtxsrc/rxtx-2.1-7r2/gnu/io/CommDriver.class] Error 1 ------------------------ Any ideas or pointers? Regards, Jeremy From tjarvi at qbang.org Sat Mar 24 08:12:54 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 Mar 2007 08:12:54 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > From Adrien.TOS at ingenico.com Sat Mar 24 11:53:22 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Sat, 24 Mar 2007 18:53:22 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> I do not have the threshold setting enabled, I have explicitely disabled it with: port_.disableReceiveThreshold(); I have also run the same tests with the threshold setting enabled, but they also fail in the same way as described below. So it seems there is a problem with timeout handling on Win32? ________________________________ From: rxtx-bounces at qbang.org on behalf of Trent Jarvi Sent: Sat 3/24/2007 3:12 PM To: RXTX Developers and Users Subject: Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 8312 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20070324/f9e39c9b/attachment-0069.bin From greg.johnson at manchester.ac.uk Sun Mar 25 13:41:36 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Sun, 25 Mar 2007 21:41:36 +0200 Subject: [Rxtx] Mac intel weirdness Message-ID: Hi folks, I'm trying to get rxtx to work on my macbook pro with a USB-serial dongle on it. I am using the 2.1-8 code from the CVS (though it seems to report itself as 2.1-7: makes it difficult to prove to oneself that the changes have 'taken'! - line 4210 in SerialImp.c, line 40 in RXTXVersion.java) I am trying the 2.1-8 because of horrible lock problems in 2.1-7. However, the serialport closure code seems to be broken - it won't close because it believes the (previously opened!) port doesn't exist. Here is what I'm trying: 0. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "false" 1. Open a port Serialport serialport = (SerialPort) commportidentifier.open ("test",100); 2. Talk to a device ... 3. Close port serialport.close(); 4. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "true" - why is this? 5. Try to reopen port Serialport serialport2 = (SerialPort) commportidentifier.open("test", 100); throws PortInUseException. I've dug around a bit in the source, and it seems the SerialPort.close () should call the CommPortIdentifier.internalClosePort() (line 67 of CommPort.java). However, I crash out with the NoSuchPortException when getPortIdentifier is called. Which seems quite weird to me, seeing as it is called on this - which was create just beforehand. Does anyone know how to fix this? Cheers, greg From knute at frazmtn.com Sat Mar 24 10:32:38 2007 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 24 Mar 2007 09:32:38 -0700 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc>, Message-ID: <4604F036.17833.135298@knute.frazmtn.com> > >The behavior of timeout depends upon the setting of the threshold. Do you >have the threshold setting? > This is the same bug I reported last fall. There was a fellow that sent me an email asking if it had been fixed. I told him I didn't think so. He got somebody to write a fix for him but I have not been able to contact him again for the actual changes. The inaccurate timeout and the failure of blocking when no timeouts are set is a serious bug in my humble opinion and renders the software unusable for my applications. I'd really like to have an alternative to the Sun comm api but there just isn't one that I know of. -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Mar 26 16:17:00 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 26 Mar 2007 16:17:00 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> Message-ID: >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. From ra85551 at gmail.com Tue Mar 27 10:18:36 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Tue, 27 Mar 2007 20:18:36 +0400 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Ultimately I found a solution. At first, that wasn't actually the VMWare + WinXP + RXTX issue, that was WinXP + RXTX issue. But on pure XP it sometimes workes, sometimes not, while under VMWare I had never seen my snippet working at all. SimpleSnuV1.java would not help me, because there is only one line I missed, and SimpleSnuV1.java also doesn't contain it! It is as follows: serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_OUT | SerialPort.FLOWCONTROL_RTSCTS_IN); Thank you for your attention. -- Pavel Parkhomenko From griff at op.pl Wed Mar 28 01:28:19 2007 From: griff at op.pl (griff@op.pl) Date: Wed, 28 Mar 2007 09:28:19 +0200 Subject: [Rxtx] No blocking read on Windows. Message-ID: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/5d07d571/attachment-0066.html -------------- next part -------------- Hi, I have problem that InputStram.read() (SerialPort)?returns -1 instead blocking and waiting for data. I found that this problem was ?known in 2005 : ? >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > >> Hi Trent >> >> Thanks for the fast response. >> Here's a Q&D test program for the blocking read on windows that just >> attempts to read one byte, and prints the resulting byte. On my system it >> returns -1, where I expect that it keeps waiting for data. >> >This isn't happening on Linux so the bug is in src/termios.c.? I'll have >something this weekend to fix that. I'm using RXTX 2.1.7r2 and the problem still is here. Im using Windows XP and java 1.5 disableReciveTimeout() and disableReciveTreshhold() dont help. ? best regards ? Piotr Zielniok From Adrien.TOS at ingenico.com Wed Mar 28 01:40:46 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Wed, 28 Mar 2007 09:40:46 +0200 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903E88880@frsnprexc1.usr.ingenico.loc> Looking at the code, it seems there is no support for infinite timeout? And maybe the count++ < 20 condition is breaking out of the loop too early? The only condition to break out of the loop should either be the timeout has expired or the number of requested bytes has been received. -----Message d'origine----- De : rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] De la part de Trent Jarvi Envoy? : mardi 27 mars 2007 00:17 ? : RXTX Developers and Users Objet : Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From j.kenneth.gentle at acm.org Wed Mar 28 06:44:15 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 28 Mar 2007 08:44:15 -0400 Subject: [Rxtx] No blocking read on Windows. In-Reply-To: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> References: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> Message-ID: <200703281844.l2SIiITW028614@qbang.org> Just another "ME TOO!" - I'm seeing this problem on Windows XP, jre for windows XP/Embedded. I cranked receiveTimeout up to Integer.MAX_INT, but it doesn't seem to wait that long At 03:28 2007-03-28, you wrote: >Hi, >I have problem that InputStram.read() (SerialPort) returns -1 >instead blocking and waiting for data. I found that this problem >was known in 2005 : > > >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > > > >> Hi Trent > >> > >> Thanks for the fast response. > >> Here's a Q&D test program for the blocking read on windows that just > >> attempts to read one byte, and prints the resulting byte. On my system it > >> returns -1, where I expect that it keeps waiting for data. > >> > > >This isn't happening on Linux so the bug is in src/termios.c. I'll have > >something this weekend to fix that. > >I'm using RXTX 2.1.7r2 and the problem still is here. >Im using Windows XP and java 1.5 >disableReciveTimeout() and disableReciveTreshhold() dont help. > >best regards > >Piotr Zielniok > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From greg.johnson at manchester.ac.uk Wed Mar 28 14:43:29 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Wed, 28 Mar 2007 22:43:29 +0200 Subject: [Rxtx] Cannot close and reopen serial port Message-ID: <377F9765-7A9D-4CE9-9176-FFB63A2594F0@manchester.ac.uk> Dear all, It appears I cannot close a port properly: SerialPort serialport = portid.open("myprog",100); // do some stuff, all works fine serialport.close(); // all seems fine but... SerialPort sp2 = portid.open("myprog",100); throws PortInUseException. And when I dig into the rxtx code, I find in CommPort.java, in close(): CommPortIdentifier cp = CommPortIdentifier.getPortIdentifier(this); (line 64 or there abouts) but this throws a NoSuchPortException which is caught but ignored (line 74ish). Can anyone suggest how this could happen: a port that was valid, opened, and used, throws a NSPE when it comes to closing it? I'm pulling my (remaining) hair out over this one! Cheers, greg PS And thanks for RXTX - it's great to have! PPS (21.-7. winxp/osx both, java 1.5) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/c28852fc/attachment-0065.html From rxtx at vrijheidslaan.net Fri Mar 30 16:52:50 2007 From: rxtx at vrijheidslaan.net (Rob) Date: Fri, 30 Mar 2007 22:52:50 -0000 Subject: [Rxtx] Cvs Question Message-ID: <61896.80.126.150.87.1175295162.squirrel@webmail.provalue.nl> Hi There, Im trying to get the latest version to work on mac osx. Problem is that i can't checkout version 2.1.8. Probably my fault but can some one please give me the alternative commands for: [user at myhost]$ export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot [user at myhost]$ cvs login Thanx, Rob From ra85551 at gmail.com Thu Mar 1 03:47:06 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Thu, 1 Mar 2007 13:47:06 +0300 Subject: [Rxtx] enableReceiveTimeout() issue Message-ID: Hello, world! I found a limitation of 16300 ms for CommPort's enableReceiveTimeout() method, while in original javax.comm docs there are no any references to that. Is that a bug or feature? I actually need longer timeouts sometimees. -- Pavel Parkhomenko From lyon at docjava.com Thu Mar 1 07:54:17 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 01 Mar 2007 09:54:17 -0500 Subject: [Rxtx] parametric singleton design pattern In-Reply-To: References: <22d55aea0702081207q5e7f6785l352d498d6f5f9fb1@mail.gmail.com> <22d55aea0702100034o3bcf42f3j1d1a6257029a67b0@mail.gmail.com> Message-ID: Hi All, I have been thinking about the use of a design pattern to cache resources that are consumed by processes. Toward that end, I have arrived at a parametric singleton design pattern, which I mentioned on this list some time ago. The idea has been published at: http://www.jot.fm/issues/issue_2007_03/column2 I can't help but think that there should be an API available for dealing with the tracking of serial port usage. Perhaps it is a kind of resource manager called the: SerialPortManager basic prototypes already exist in this vain. See, for example: http://www.ce.rit.edu/research/projects/2005_fall/rt_poolsystem/doc/PoolMon/SerialPortManager.html http://www.eventhelix.com/RealtimeMantra/PatternCatalog/serial_port_design_pattern.htm And others shown by a google search on "SerialPortManager" Cheers! - Doug From Eric.Arseneau at sun.com Thu Mar 1 10:15:03 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:15:03 -0800 Subject: [Rxtx] Any known Java 6 issues with RXTX 2.1-7r2 ? Message-ID: <45E70A17.1060206@sun.com> I just did a test on a recent build of Solaris 11 x86 and it seems that I can connect to my serial device fine when Java 5 is the default, but when Java 6 is the default, no go. Any information ? From Eric.Arseneau at sun.com Thu Mar 1 10:19:58 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:19:58 -0800 Subject: [Rxtx] Mac OS X and missing data Message-ID: <45E70B3E.7040908@sun.com> We have a device which is USB based but presents itself as a serial port to a machine. On my MacBook Pro I can get excellent throughput if I get my device to send data as quickly as possible. On the desktop side, if I do an type of disk IO to log the data I get, I end up with some missing data at some point. I hooked up a USB analyzer and did confirm that all the data is sent as expected to the desktop from the device. I found a work around for this, buffer the data in memory and only write the data out when I've received it all. However, when the same code and same device is attempted on a co-workers MacBook Pro (same hardware specs), I get errors and must slow down dramatically the device side's sending of data. Any ideas/recommendations on what I can do to get rid of this error ? From what I can tell, it seems that RXTX is not able to wake up to the interrupts coming in indicating data is ready, quickly enough, is there anything I can do ? From chinkaiw at hotmail.com Fri Mar 2 00:57:43 2007 From: chinkaiw at hotmail.com (Wang Chinkai) Date: Fri, 02 Mar 2007 07:57:43 +0000 Subject: [Rxtx] dynamic detect rs232 port Message-ID: Hi all I have a question about detecting rs232 port dynamicly. I have to aceess some port and detect rs232 port at the same time. Some usb device simulates rs232 port , and I can not know what the port name it gets until it connects,so I have to detect it dynamic,but I have to access another rs232 device at the same time. I found a problem. If I use CommPortIdentifier.getPortIdentifiers() to get new port list , and the other rs232 access function will not close port correctly. So , How can I solve it . Thanks. _________________________________________________________________ ?? 2GB ???? Windows Live Mail ????????????? http://ideas.live.com/programpage.aspx?versionid=5d21c51a-b161-4314-9b0e-4911fb2b2e6d From eu259473 at tele2.it Fri Mar 2 06:16:40 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 02 Mar 2007 14:16:40 +0100 Subject: [Rxtx] rxtx on HP tru 64 unix Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070302/706c7a70/attachment-0093.html From tjarvi at qbang.org Fri Mar 2 08:39:33 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 08:39:33 -0700 (MST) Subject: [Rxtx] rxtx on HP tru 64 unix In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, "Giuseppe Marchese" wrote: > Hi > > I try to install rxtx on hp tru 64 but make fails, > There are somebody that do the same and work. > > > Sorry for may english! > > Hi Giuseppe Could you provide a log of the failure? script ./configure make # use gnu make exit The information will be in the typescript created. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 2 19:56:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 19:56:52 -0700 (MST) Subject: [Rxtx] dynamic detect rs232 port In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, Wang Chinkai wrote: > Hi all > > I have a question about detecting rs232 port dynamicly. > > I have to aceess some port and detect rs232 port at the same time. > Some usb device simulates rs232 port , and I can not know > what the port name it gets until it connects,so I have to detect it > dynamic,but I have to access > another rs232 device at the same time. > > I found a problem. Hi Wang This is a known problem. The code is braindead there. In fact there needs to be events even in a rudamentary way when you add a usb dongle. I'm burried in tasks not far from rxtx but not in rxtx. I can't get to the problem but we would accept patches if you dig into it. [I'm getting to the license question earlier too; I don't have another 10%] -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Fri Mar 2 23:19:01 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 01:19:01 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Hi, Under ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable USB -> serial converter(using virtual com port drivers), with using example code pretty much straight out of http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port opens fine, enumerations all work, etc. My application calls for a large amount of data to be transferred in a short amount of time at 2,000,000 baud. My hardware sends approximately 15,232 bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL converter work fine, and the application works using C++. In C++, I do a hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); to open the port, and a boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); to read the port. The variable buffer fills with the 15238 bytes, and returns. If I do a resultz = is.read(cbuf,0,15238); in java with RXTX where is = new BufferedReader(new InputStreamReader(port.getInputStream())); and where resultz is an int, and cbuf is a char [] cbuf, resultz gets EXACTLY 3968 bytes the first time called. If I call it multiple times, I get roughly 11k total(less than what is sent), never more than the 3968 bytes per is.read() call. My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 bytes. I've played with inputbuffersize, receive threshold, receivetimeout, and so on. The FTDI virtual com port drivers that I'm using are rock solid, and have had zero problems with them using a variety of applications, some of my own, some professionally written, etc. No flow control is used anyplace, no RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. No exceptions are being thrown. What am I doing wrong, and what I can adjust to receive the full 15k bytes in one single read? Thanks! Keith From Eric.Arseneau at sun.com Fri Mar 2 23:32:07 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Fri, 02 Mar 2007 22:32:07 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <45E91667.20501@sun.com> This is the same type of thing that is happening to me on Mac OS X and does not seem to behave the same on different machines. I posted a day or two ago on this with subject "Mac OS X and missing data". Would love to hear if there is a solution to this :) From tjarvi at qbang.org Sat Mar 3 10:54:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 10:54:17 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > Hi, > > Under > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable > USB -> serial converter(using virtual com port drivers), with using example > code pretty much straight out of > http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port > opens fine, enumerations all work, etc. > > My application calls for a large amount of data to be transferred in a short > amount of time at 2,000,000 baud. My hardware sends approximately 15,232 > bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL > converter work fine, and the application works using C++. > > In C++, I do a > > hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, > OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); > > to open the port, and a > > boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); > > to read the port. > > The variable buffer fills with the 15238 bytes, and returns. > > If I do a > > resultz = is.read(cbuf,0,15238); in java with RXTX > > where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > > and where resultz is an int, and cbuf is a char [] cbuf, resultz gets > EXACTLY 3968 bytes the first time called. If I call it multiple times, I get > roughly 11k total(less than what is sent), never more than the 3968 bytes > per is.read() call. > > My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 > bytes. > > I've played with inputbuffersize, receive threshold, receivetimeout, and so > on. The FTDI virtual com port drivers that I'm using are rock solid, and > have had zero problems with them using a variety of applications, some of my > own, some professionally written, etc. No flow control is used anyplace, no > RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. > > No exceptions are being thrown. > > What am I doing wrong, and what I can adjust to receive the full 15k bytes > in one single read? > > Thanks! > Hi Keith I would expect a 20 meg application is going to have different behavior with the OS than a smaller application with respect to the kernel memory managment, schedualing, ... Something subtle could be causing problems. With respect to the recieve timeout and threshold, if you set the timeout to zero and the threshold to the size of data you expect, read should not return until it get that data. You may try with a stand alone application that tests just that with the C/C++ API. If the read is returning with less data when tested for short reads, you have found a bug in the device driver more than likely. The USB dongle vendor would probably be interested in knowing about this. As mentioned, these devices are getting very good; almost bug free. I suspect you found a bug though if you did use the threshold and timeout properly. The missing data is typical when not using flow control. When the OS buffering fills, the hardware will start dropping bytes. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:38:52 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:38:52 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> update: I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now instead of 3968. This makes sense. 128 bytes of overhead + 3968 bytes of data = 4096 transfer size 32 bytes of overhead + 992 bytes of data = 1024 transfer size. 1/4 the data = 1/4 the overhead. I rearranged my reading like so: resultz = is.read(cbuf,0,3968); resultz = is.read(cbuf,3968,3968); resultz = is.read(cbuf,7936,3968); while (!(is.ready())); // wait for ready resultz = is.read(cbuf,11904,3334); and this grabs 15,238 bytes total. BUT, I still have the quandry of the screwed up multi-bytes. I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. Approx 8% of the data. The bad bytes always seem to take the flavor of 0x2018, 0x2019, x2022, x2030, x201d. Are these maybe errors and I don't know what they enumerate to? I still can't believe some other layer isn't handling putting those bytes together all in one stream for me. Thanks Keith ----- Original Message ----- From: "Keith" To: "Bob Jacobsen" ; "RXTX Developers and Users" Sent: Saturday, March 03, 2007 11:26 AM Subject: Re: [Rxtx] is.read() only returning 3968 bytes > Bob, > > > Interesting numerical coincidence is that (max USB transfer) - (what > > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > > needed to transfer that much data. > > I was thinking along the same lines. I don't know USB well, but I do know > that those numbers were close enough to warrant investigating the > relationship between them. > > > I think what you're seeing is the internal buffering of the USB data > > stream. You'll need some form of higher-level buffering to smooth > > that out. > > Shouldn't the InputStreamReader() and BufferedReader() provide this type of > buffering? Isn't that the idea behind those? > > > All hypotheses need to be tested. In this case, a test would be to > > check for missing data. If this idea is right, you'll get _all_ the > > data, but you won't be missing characters. > > I did start looking at the data. -- I'm getting weird results. > > I tried this: > > loopzz = 0; > > for (looptwo = 0; looptwo < 100000; looptwo++) { > while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > > }} > > So I'm reading one character at a time. The good news is that loopzz is > exactly 15238 at the end of the routine, which is perfectly correct. I > picked looptwo value out of thin air. > > The weird results come in terms of the values, the data isn't correct at > least in one case. Look here: > > 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > > This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). > But the 0x89 was replaced by 0x2030. Why the heck would the returned value > be 0x2030?? Why is the returned byte completely out of range? Why the > multibyte return? > > From InputStream in the API: > > read > public abstract int read() > throws IOExceptionReads the next byte of data from the > input stream. The value byte is returned as an int in the range 0 to 255. If > no byte is available because the end of the stream has been reached, the > value -1 is returned. This method blocks until input data is available, the > end of the stream is detected, or an exception is thrown. > Value should be 0-255. > > > In my application time is really critical, reading 1 byte at a time is > probably not going to work. > > Thanks Eric & Bob for looking at this. > > Keith > From tjarvi at qbang.org Sat Mar 3 12:52:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 12:52:27 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > update: > > I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now > instead of 3968. > > This makes sense. > > 128 bytes of overhead + 3968 bytes of data = 4096 transfer size > 32 bytes of overhead + 992 bytes of data = 1024 transfer size. > > 1/4 the data = 1/4 the overhead. > > I rearranged my reading like so: > > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. > Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? > > I still can't believe some other layer isn't handling putting those bytes > together all in one stream for me. > The layer for this in Serial land is flow control. Software and hardware flow control prevent the overruns you observe. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:54:41 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:54:41 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <001a01c75dcd$c8802a70$6600a8c0@jbh757ktruws7g> Trent, Thanks for taking the time to reply. > I would expect a 20 meg application is going to have different behavior > with the OS than a smaller application with respect to the kernel memory > managment, schedualing, ... Something subtle could be causing problems. Well, at least I know the VCP drivers, the OS, etc can handle 2mbps reliably. Without hiccuping or dropping bytes. The C++ code works reliably without flow control. > The missing data is typical when not using flow control. When the OS > buffering fills, the hardware will start dropping bytes. I'm actually not getting MISSING data, I'm getting CORRUPTED data. If you look at my most recent post, I'm getting these bad bytes in place of the correct values: 0x2018, 0x2019, x2022, x2030, x201d. Why would is.read() return values not in the range of 0-255 ? Thanks. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 08:59:14 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 07:59:14 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: At 1:19 AM -0500 3/3/07, Keith wrote: >If I do a > >resultz = is.read(cbuf,0,15238); in java with RXTX > >where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > >and where resultz is an int, and cbuf is a char [] cbuf, resultz gets >EXACTLY 3968 bytes the first time called. If I call it multiple times, I get >roughly 11k total(less than what is sent), never more than the 3968 bytes >per is.read() call. > >My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 >bytes. Interesting numerical coincidence is that (max USB transfer) - (what you get) = 4096-3968 = 128 bytes is (almost) the size of the headers needed to transfer that much data. I think what you're seeing is the internal buffering of the USB data stream. You'll need some form of higher-level buffering to smooth that out. All hypotheses need to be tested. In this case, a test would be to check for missing data. If this idea is right, you'll get _all_ the data, but you won't be missing characters. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 09:26:14 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 11:26:14 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Bob, > Interesting numerical coincidence is that (max USB transfer) - (what > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > needed to transfer that much data. I was thinking along the same lines. I don't know USB well, but I do know that those numbers were close enough to warrant investigating the relationship between them. > I think what you're seeing is the internal buffering of the USB data > stream. You'll need some form of higher-level buffering to smooth > that out. Shouldn't the InputStreamReader() and BufferedReader() provide this type of buffering? Isn't that the idea behind those? > All hypotheses need to be tested. In this case, a test would be to > check for missing data. If this idea is right, you'll get _all_ the > data, but you won't be missing characters. I did start looking at the data. -- I'm getting weird results. I tried this: loopzz = 0; for (looptwo = 0; looptwo < 100000; looptwo++) { while (is.ready()) { cbuf[loopzz] = (char) is.read(); loopzz++; }} So I'm reading one character at a time. The good news is that loopzz is exactly 15238 at the end of the routine, which is perfectly correct. I picked looptwo value out of thin air. The weird results come in terms of the values, the data isn't correct at least in one case. Look here: 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). But the 0x89 was replaced by 0x2030. Why the heck would the returned value be 0x2030?? Why is the returned byte completely out of range? Why the multibyte return? >From InputStream in the API: read public abstract int read() throws IOExceptionReads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown. Value should be 0-255. In my application time is really critical, reading 1 byte at a time is probably not going to work. Thanks Eric & Bob for looking at this. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 14:44:50 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 13:44:50 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: Java's "char" type is Unicode. I think what you're seeing is a bug in the byte -> Unicode translation. 0x2018, 0x2019 are the curly open and close quotes. There used to be (and might still be) bugs in the conversion of these in a couple of libc versions. Some of the ASCII -> ISO and ISO -> ASCII routines were a little over-ambitious with respect to handling the open and close quotes, and tried to convert them to the "curly" form inappropriately. Try _not_ casting it to char. Bob At 11:26 AM -0500 3/3/07, Keith wrote: >Bob, > >> Interesting numerical coincidence is that (max USB transfer) - (what >> you get) = 4096-3968 = 128 bytes is (almost) the size of the headers >> needed to transfer that much data. > >I was thinking along the same lines. I don't know USB well, but I do know >that those numbers were close enough to warrant investigating the >relationship between them. > >> I think what you're seeing is the internal buffering of the USB data >> stream. You'll need some form of higher-level buffering to smooth >> that out. > >Shouldn't the InputStreamReader() and BufferedReader() provide this type of >buffering? Isn't that the idea behind those? > >> All hypotheses need to be tested. In this case, a test would be to >> check for missing data. If this idea is right, you'll get _all_ the >> data, but you won't be missing characters. > >I did start looking at the data. -- I'm getting weird results. > >I tried this: > >loopzz = 0; > >for (looptwo = 0; looptwo < 100000; looptwo++) { >while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > >}} > >So I'm reading one character at a time. The good news is that loopzz is >exactly 15238 at the end of the routine, which is perfectly correct. I >picked looptwo value out of thin air. > >The weird results come in terms of the values, the data isn't correct at >least in one case. Look here: > >0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > >This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). >But the 0x89 was replaced by 0x2030. Why the heck would the returned value >be 0x2030?? Why is the returned byte completely out of range? Why the >multibyte return? > >>From InputStream in the API: > >read >public abstract int read() > throws IOExceptionReads the next byte of data from the >input stream. The value byte is returned as an int in the range 0 to 255. If >no byte is available because the end of the stream has been reached, the >value -1 is returned. This method blocks until input data is available, the >end of the stream is detected, or an exception is thrown. >Value should be 0-255. > > >In my application time is really critical, reading 1 byte at a time is >probably not going to work. > >Thanks Eric & Bob for looking at this. > >Keith > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 15:10:11 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 17:10:11 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Bob said ..... > Java's "char" type is Unicode. I think what you're seeing is a bug > in the byte -> Unicode translation. Bob -- I think you hit the nail on the head. I was just coming to the same realization here. I knew that something funny was going on because the same bytes always got "corrupted." I'm pretty sure its in the InputStreamReader() functionality where the conversion junk is happening. Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. I don't know if simply changing the cast is going to work. Since the conversion is happening upstream (pun intended), I don't think my cast is doing this. Also I think the compiler forced me to use the cast. I'm still playing around, and I'll report back once I nail it down. Thanks!! Keith From tjarvi at qbang.org Sat Mar 3 15:59:46 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 15:59:46 -0700 (MST) Subject: [Rxtx] Win64 rxtx Testers? Message-ID: I have compiled win64 binaries of rxtx. Are there any users interested in testing them? If so, I'll look into putting them on the web site. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Mar 3 15:35:06 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 14:35:06 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: Because of this and similar problems, JMRI does all it's serial IO using +only+ byte values. It's a but of a pain, as Java wants to go to char and int types a little too aggressively, but it does solve the "uncontrolled conversions" problems. Bob At 5:10 PM -0500 3/3/07, Keith wrote: >Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > >Bob -- I think you hit the nail on the head. > >I was just coming to the same realization here. I knew that something funny >was going on because the same bytes always got "corrupted." > >I'm pretty sure its in the InputStreamReader() functionality where the >conversion junk is happening. > >Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > >I don't know if simply changing the cast is going to work. Since the >conversion is happening upstream (pun intended), I don't think my cast is >doing this. Also I think the compiler forced me to use the cast. -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mark at mdsh.com Sun Mar 4 11:01:33 2007 From: mark at mdsh.com (Mark Himsley) Date: Sun, 04 Mar 2007 18:01:33 +0000 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: <5C01AC72C200388815C04982@bedroom.mdsh.local> On 03 March 2007 14:38 -0500 Keith wrote: > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT > consistent. Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? It looks like you need to use DataInputStream and DataOutputStream. -- Mark Himsley From tjarvi at qbang.org Sun Mar 4 11:35:08 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 11:35:08 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" > > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > > * Line #21 - Not sure if you need a (TM) mark for > the term "Sun" > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > OK. I'm going through this today. Some groups ask if rxtx could be under their license also. I think this is a good example of why I resist multiple licenses and focus on why the current license may not be usable by them. The RXTX project is a convergence of hobby and commercial interests. I happen to do both right now. The problem with licensing is we have to stay on top of them as they change. Clearly, adding more licenses will not make this easier. I'm acting as the hobby person today. RXTX always favors the hobby people. But as we move forward, I'm going to need to bring this to lawyers at work and explain to them what is going on. Others here may have to do this also. I don't anticipate problems or unexpected changes. The goal is a consistant, comprehendable and usable license as close to what we have now as possible. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 14:52:10 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 14:52:10 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (1/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: I'm breaking this into two parts. I expect the second part will need more attention. Comments first, then the changed material below. On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > Thanks > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. OK. RXTX for consitent use. java should not be capitalized because it does not only mean Sun [TM] Java [TM]. An example of this not meaning Java is when people use RXTX with GCJ. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". There are not any contributors that are in all of RXTX yet but I did update the comment to try to reflect the current situation without making it a nightmare to maintain. I looked to see how the Linux kernel does it as a reference point. > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" The URL can be problematic. I have done so below with a time reference. GNU does not provide version information in their URLS. I picture this being a problem when the version 3 comes out. > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > This will be corrected when the copy is updated to the version linked below. ---------------- begin proposed material involved -------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. ----------------- end proposed material involved -------------------- I'll be looking at the linking issue again next. That should be all that remains other than including the 2.1 version. Let me know if you have problems with anything here. I do not want to dilute the material I post next with these housekeeping tasks. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 16:08:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 16:08:36 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: For those that are wondering what is going on here, this next bit is the meat of the changes. We agreed a long time ago to put this disclaimer in. We did a so so job. It was in rxtx 2.0, not well written, ... So some groups using rxtx that would like to ship rxtx so users don't need to download, install, go to the mail-list to find why it failed, ... Then their legal teams tell them section 5 paragraph 2 is a show stopper. That was never the intent. Now going through what remains... > and might need a (TM) suffix to make Sun happy. Added disclaimer at the ended 'all trademarks belong...' > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. OK. As you can see I was trying to adjust GNU text there for the LGPL. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. used dynamically linked terminology. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". I tried to address this more upfront with an intent statement. Let me know if you have problems with it. I also tried to make it a little more clear what was derived from the GNU solution by moving the link location closer to GNU's suggestion. > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > Thats the intent. Here is the combined fixes. Note that only the material in /*-- --*/ is being touched. The new GPL license is there but unmodified. ------------------------ begin proposed new license ------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. | | An executable that contains no derivative of any portion of RXTX, but | is designed to work with RXTX by being dynamically linked with it, | is considered a "work that uses the Library" subject to the terms and | conditions of the GNU Lesser General Public License. | | The following has been added to the RXTX License to remove | any confusion about linking to RXTX. We want to allow in part what | section 5, paragraph 2 of the LGPL does not permit in the special | case of linking over a controlled interface. The intent is to add a | Java Specification Request or standards body defined interface in the | future as another exception but one is not currently available. | | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface | | As a special exception, the copyright holders of RXTX give you | permission to link RXTX with independent modules that communicate with | RXTX solely through the Sun Microsytems CommAPI interface version 2, | regardless of the license terms of these independent modules, and to copy | and distribute the resulting combined work under terms of your choice, | provided that every copy of the combined work is accompanied by a complete | copy of the source code of RXTX (the version of RXTX used to produce the | combined work), being distributed under the terms of the GNU Lesser General | Public License plus this exception. An independent module is a | module which is not derived from or based on RXTX. | | Note that people who make modified versions of RXTX are not obligated | to grant this special exception for their modified versions; it is | their choice whether to do so. The GNU Lesser General Public License | gives permission to release a modified version without this exception; this | exception also makes it possible to release a modified version which | carries forward this exception. | | You should have received a copy of the GNU Lesser General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA | All trademarks belong to their respective owners. --------------------------------------------------------------------------*/ The original GNU Lesser General Public License Follows. GNU LESSER GENERAL PUBLIC LICENSE Version 2.1, February 1999 Copyright (C) 1991, 1999 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. [This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence the version number 2.1.] Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This license, the Lesser General Public License, applies to some specially designated software packages--typically libraries--of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below. When we speak of free software, we are referring to freedom of use, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish); that you receive source code or can get it if you want it; that you can change the software and use pieces of it in new free programs; and that you are informed that you can do these things. To protect your rights, we need to make restrictions that forbid distributors to deny you these rights or to ask you to surrender these rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library or if you modify it. For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights. We protect your rights with a two-step method: (1) we copyright the library, and (2) we offer you this license, which gives you legal permission to copy, distribute and/or modify the library. To protect each distributor, we want to make it very clear that there is no warranty for the free library. Also, if the library is modified by someone else and passed on, the recipients should know that what they have is not the original version, so that the original author's reputation will not be affected by problems that might be introduced by others. Finally, software patents pose a constant threat to the existence of any free program. We wish to make sure that a company cannot effectively restrict the users of a free program by obtaining a restrictive license from a patent holder. Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license. Most GNU software, including some libraries, is covered by the ordinary GNU General Public License. This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs. When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library. We call this license the "Lesser" General Public License because it does Less to protect the user's freedom than the ordinary General Public License. It also provides other free software developers Less of an advantage over competing non-free programs. These disadvantages are the reason we use the ordinary General Public License for many libraries. However, the Lesser license provides advantages in certain special circumstances. For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License. In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software. For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU operating system, as well as its variant, the GNU/Linux operating system. Although the Lesser General Public License is Less protective of the users' freedom, it does ensure that the user of a program that is linked with the Library has the freedom and the wherewithal to run that program using a modified version of the Library. The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, whereas the latter must be combined with the library in order to run. GNU LESSER GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License Agreement applies to any software library or other program which contains a notice placed by the copyright holder or other authorized party saying it may be distributed under the terms of this Lesser General Public License (also called "this License"). Each licensee is addressed as "you". A "library" means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables. The "Library", below, refers to any such software library or work which has been distributed under these terms. A "work based on the Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term "modification".) "Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library. Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does. 1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) The modified work must itself be a software library. b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change. c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License. d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful. (For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library. In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. 4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange. If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code. 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables. When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law. If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.) Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself. 6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications. You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things: a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.) b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. c) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution. d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place. e) Verify that the user has already received a copy of these materials or that you have already sent this user a copy. For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute. 7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things: a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above. b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work. 8. You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 9. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Library (or any work based on the Library), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Library or works based on it. 10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties with this License. 11. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply, and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 12. If the distribution and/or use of the Library is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Library under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 13. The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation. 14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Libraries If you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the ordinary General Public License). To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Also add information on how to contact you by electronic and paper mail. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the library, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the library `Frob' (a library for tweaking knobs) written by James Random Hacker. , 1 April 1990 Ty Coon, President of Vice That's all there is to it! ------------------------ end of proposed license ------------------ -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sun Mar 4 16:26:04 2007 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 04 Mar 2007 17:26:04 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <45EB558C.3010609@cox.net> Bob Jacobsen wrote: > Because of this and similar problems, JMRI does all it's serial IO > using +only+ byte values. It's a but of a pain, as Java wants to go > to char and int types a little too aggressively, but it does solve > the "uncontrolled conversions" problems. Anytime that you are reading bytes of data that is not printable, unicode text, in Java, you really need to stay away from the Readers. Use input stream only, or you will see unicode valued byte groups converted to unicode "char" values. Gregg Wonderly From joachim at buechse.de Mon Mar 5 04:23:48 2007 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 5 Mar 2007 12:23:48 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> The behaviour is exactly what you asked for in you code. is = new BufferedReader(new InputStreamReader(port.getInputStream())); Readers return Text (ie unicode chars) not bytes. You instantiate the InputStreamReader without saying which charset you want, which means "platform default". As this is on Windows, it will convert Windows characters to equivalent unicode characters. If you want to read bytes, read bytes not Text. Reading bytes is done with InputStream and BufferedInputStream. BTW: The InputStream and Reader methods that read arrays are not guarenteed to fill up the array. You always have to check what you really got, and advance your index accordingly. A typical "read up to 32k" method looks like this: InputStream is= ... // -- determine the max buffer size int len= is.available(); if (len == 0) { len= 32 * 1024; } // -- read all available data byte[] buffer= new byte[len]; int pos= 0; int read; do { read= is.read(buffer, pos, buffer.length - pos); pos= pos + read; } while (read != -1 && pos < buffer.length); Best regards, Joachim --- Joachim B?chse Phone: +41 44 500 2604 Buechse Consulting Hadlaubsteig 2 CH-8006 Z?rich On 03.03.2007, at 23:10, Keith wrote: > Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > > Bob -- I think you hit the nail on the head. > > I was just coming to the same realization here. I knew that > something funny > was going on because the same bytes always got "corrupted." > > I'm pretty sure its in the InputStreamReader() functionality where the > conversion junk is happening. > > Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > > I don't know if simply changing the cast is going to work. Since the > conversion is happening upstream (pun intended), I don't think my > cast is > doing this. Also I think the compiler forced me to use the cast. > > I'm still playing around, and I'll report back once I nail it down. > > Thanks!! > > Keith > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Mon Mar 5 07:25:46 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 05 Mar 2007 08:25:46 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> Message-ID: <45EC286A.8060608@cox.net> Joachim Buechse wrote: > BTW: The InputStream and Reader methods that read arrays are not > guarenteed to fill up the array. You always have to check what you > really got, and advance your index accordingly. A typical "read up to > 32k" method looks like this: > > InputStream is= ... > // -- determine the max buffer size > int len= is.available(); > if (len == 0) { > len= 32 * 1024; > } > // -- read all available data > byte[] buffer= new byte[len]; > int pos= 0; > int read; > do { > read= is.read(buffer, pos, buffer.length - pos); > pos= pos + read; > } while (read != -1 && pos < buffer.length); > My preferred structure is. byte arr[ len ]; int cnt; int off = 0; while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { off += cnt; } This keeps you from adding -1 to pos when the read returns -1. It also skips out when the read is 0 bytes which, is not a described EOF in InputStream java docs, but is a condition I want to be aware of. Gregg Wonderly From joachim at buechse.de Tue Mar 6 02:52:58 2007 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 6 Mar 2007 10:52:58 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <45EC286A.8060608@cox.net> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: The code I copied was from a file resource reader, it shouldn't really be applied to networking/external IO code. Mea culpa. However aborting when you get 0 from read is not always what you want either (you kind of indicated that already). Some unix java implementations will return 0 if the kernel read was aborted with EINTER, which is rarely the point where you want to abort your read - at least not without further checks. A "complete" solution always depends on the events you need to handle and the time the total read could take in reality. In some cases it's worth checking Thread.isInterrupted() in the loop, some code re-loops on 0 but only a limited number of times, some check a total timeout limit, etc... Best regards, Joachim On 05.03.2007, at 15:25, Gregg Wonderly wrote: > My preferred structure is. > > byte arr[ len ]; > int cnt; > int off = 0; > while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { > off += cnt; > } > > This keeps you from adding -1 to pos when the read returns -1. It > also skips > out when the read is 0 bytes which, is not a described EOF in > InputStream java > docs, but is a condition I want to be aware of. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Mar 6 14:47:44 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 Mar 2007 14:47:44 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: Just FYI, rxtx will usually not break out on EINTER. The code in the native library usually does something close to this: do { read(...) } while ( !done && errno==EINTR ); Obviously there is a little more involved but it will retry on EINTER if not done. On Tue, 6 Mar 2007, Joachim Buechse wrote: > The code I copied was from a file resource reader, it shouldn't > really be applied to networking/external IO code. Mea culpa. > > However aborting when you get 0 from read is not always what you want > either (you kind of indicated that already). Some unix java > implementations will return 0 if the kernel read was aborted with > EINTER, which is rarely the point where you want to abort your read - > at least not without further checks. A "complete" solution always > depends on the events you need to handle and the time the total read > could take in reality. In some cases it's worth checking > Thread.isInterrupted() in the loop, some code re-loops on 0 but only > a limited number of times, some check a total timeout limit, etc... > > Best regards, > Joachim > > On 05.03.2007, at 15:25, Gregg Wonderly wrote: >> My preferred structure is. >> >> byte arr[ len ]; >> int cnt; >> int off = 0; >> while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { >> off += cnt; >> } >> >> This keeps you from adding -1 to pos when the read returns -1. It >> also skips >> out when the read is 0 bytes which, is not a described EOF in >> InputStream java >> docs, but is a condition I want to be aware of. >> >> Gregg Wonderly >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 gjhanna at gmail.com Thu Mar 8 13:42:52 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Fri, 9 Mar 2007 09:42:52 +1300 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? Message-ID: I've just struck an issue using rxtx in a multi-threaded environment: If I have 3 threads trying to open *the same* comm-port I get a deadlock in CommPortIdentifier.open If I have just 2, it works fine - I get a PortInUseException which is nice and I can handle it. The 3 thread->deadlock thing is causing me issues. (Sample code below). This is from the java thread-dump Found one Java-level deadlock: ============================= "Thread-2": waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object ), which is held by "Thread-1" "Thread-1": waiting to lock monitor 0x0003e9cc (object 0x2450e108, a gnu.io.CommPortIdentifier), which is held by "Thread-2" Java stack information for the threads listed above: =================================================== "Thread-2": at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:329) - waiting to lock <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) "Thread-1": at java.lang.Object.wait(Native Method) - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) - locked <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) (Apart from this, rxtx is working fantastically for us). I'm thinking I'll have to implement some sort of locking mechanism that *doesn't* use java synchronization to prevent this situation. (Which doesn't sound like a good idea to me). Any ideas? Thanks, Greg Hanna ============= RXTXLockTest.java ======================================== import gnu.io.CommPort; import gnu.io.CommPortIdentifier; /** * @author Greg Hanna * Minimal code to create a deadlock with rxtx in multithreaded open */ public class RXTXLockTest { public static void main(String[] args) { try { CommPortIdentifier cpiCom1 = CommPortIdentifier.getPortIdentifier ("COM14"); OpenThread t1 = new OpenThread (" one ", cpiCom1); OpenThread t2 = new OpenThread (" two ", cpiCom1); OpenThread t3 = new OpenThread (" 003 ", cpiCom1); t1.start(); t2.start(); t3.start(); // comment this out and it runs with (expected) PortInUseException } catch (Exception e) { e.printStackTrace(); } } } class OpenThread extends Thread { String name; CommPortIdentifier cpi; CommPort cp; public OpenThread (String name, CommPortIdentifier cpi) { this.name = name; this.cpi = cpi; System.out.println (System.currentTimeMillis() + name + " thread created"); } public void run () { try { System.out.println (System.currentTimeMillis() + name + " opening"); cp = cpi.open(name, 2000); System.out.println (System.currentTimeMillis() + name + " opened - sleeping"); sleep (2000); // do the serial comms with the device. System.out.println (System.currentTimeMillis() + name + " slept - closing"); cp.close(); System.out.println (System.currentTimeMillis() + name + " closed - exiting"); } catch (Exception e) { System.out.println ("Error in thread: " + name ); e.printStackTrace(); } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070308/d9a163c5/attachment-0086.html From eu259473 at tele2.it Fri Mar 9 02:46:20 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 09 Mar 2007 10:46:20 +0100 Subject: [Rxtx] rxtx: tru64 unix make fails Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070309/3b654523/attachment-0086.html From lyon at docjava.com Fri Mar 9 03:58:32 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 Mar 2007 05:58:32 -0500 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi All, The deadlock issue is one that I have been thinking about for some time now. It seems to me that we need a resource manager that enables assignment to a known process. The one thing that seems important about serial ports is that two applications should not use the same serial port at the same time. When this happens, it throws an exception. OK. The exception is a response to a lock condition that arises from an unavailable resource. An abstract implementation (not born of native methods) might assign a serial port to an application, until the application releases it (or is forced to release it by some kill mechanism). Some resources (like a registry) can be reused. But others, like the serial port, cannot. In the case of the serial port, we would like, I think, to have the flyweight design pattern without sharing and with object assignment tracking. A means of breaking deadlock (like a leasing mechanism) seems very useful, to me. My guess is that we can serialize the state of the Parametric Singleton Pattern (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) into the Preferences of the System. Preferences.systemRoot() might help with that. When a resource is checked out, the lease time and owner are listed. A thread that does this can be killed, but applications outside of Java are problematic. There is a compelling problem here. It is not just serial ports. Sound cards, cameras, microphones, files, tape drives, etc. All are consumed resources that are assigned to an application (or user) and deprive other applications, or users, from use. What, if anything, should we do? At present we throw PortInUseExceptions. Is that it? Can we do better? OK, the port is in use. Now what? Do I have to be root to go remove lock files and kill applications? Is there a better way? Thanks! - Doug >I've just struck an issue using rxtx in a multi-threaded environment: > >If I have 3 threads trying to open *the same* >comm-port I get a deadlock in >CommPortIdentifier.open >If I have just 2, it works fine - I get a >PortInUseException which is nice and I can >handle it. > >The 3 thread->deadlock thing is causing me issues. >(Sample code below). > >This is from the java thread-dump > >Found one Java-level deadlock: >============================= >"Thread-2": > waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), > which is held by "Thread-1" >"Thread-1": > waiting to lock monitor 0x0003e9cc (object >0x2450e108, a gnu.io.CommPortIdentifier ), > which is held by "Thread-2" > >Java stack information for the threads listed above: >=================================================== >"Thread-2": > at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) > - waiting to lock <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) >"Thread-1": > at java.lang.Object.wait(Native Method) > - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) > - locked <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) > > >(Apart from this, rxtx is working fantastically for us). > >I'm thinking I'll have to implement some sort of >locking mechanism that *doesn't* use java >synchronization to prevent this situation. >(Which doesn't sound like a good idea to me). > >Any ideas? > >Thanks, > >Greg Hanna > >============= RXTXLockTest.java ======================================== > >import gnu.io.CommPort; >import gnu.io.CommPortIdentifier; > >/** > * @author Greg Hanna > * Minimal code to create a deadlock with rxtx in multithreaded open > */ >public class RXTXLockTest { > ? > ?public static void main(String[] args) { > ?try { > ?CommPortIdentifier cpiCom1 = >CommPortIdentifier.getPortIdentifier ("COM14"); > ?OpenThread t1 = new OpenThread (" one ", cpiCom1); > ?OpenThread t2 = new OpenThread (" two ", cpiCom1); > ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); > ?t1.start(); > ?t2.start(); > ?t3.start(); // comment this out >and it runs with (expected) PortInUseException > ?} catch (Exception e) { > ?e.printStackTrace(); > ?} > ?} >} > >class OpenThread extends Thread { > ?String name; > ?CommPortIdentifier cpi; > ?CommPort cp; > ?public OpenThread (String name, CommPortIdentifier cpi) { > ? this.name = name; > ?this.cpi = cpi; > ?System.out.println >(System.currentTimeMillis() + name + " thread >created"); > ?} > ?public void run () { > ?try { > ?System.out.println >(System.currentTimeMillis() + name + " opening"); > ?cp = cpi.open(name, 2000); > ?System.out.println >(System.currentTimeMillis() + name + " opened - >sleeping"); > ?sleep (2000); // do the serial comms with the device. > ?System.out.println >(System.currentTimeMillis() + name + " slept - >closing"); > ?cp.close(); > ?System.out.println >(System.currentTimeMillis() + name + " closed - >exiting"); > ?} catch (Exception e) { > System.out.println ("Error in thread: " + name ); > ?e.printStackTrace(); > ?} > ?} >} > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Mar 9 06:37:45 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 Mar 2007 06:37:45 -0700 (MST) Subject: [Rxtx] rxtx: tru64 unix make fails In-Reply-To: References: Message-ID: On Fri, 9 Mar 2007, "Giuseppe Marchese" wrote: > Sorry for delay. > ? > This is log for ./configure and make > error. > ? > thanks for attention > ? > Make: '%.java,$(TOP)/$(CLASSDEST)/%.class,$(wildcard $(SPATH)/*.java)': extra chars.? > Stop. > Hi Giuseppe You need to use GNU make with the Makefile. I suspect the tru64 make is not happy with those rules. > configure: exit 0 Looks like configure is fairly happy. From tjarvi at qbang.org Sat Mar 10 07:43:51 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 07:43:51 -0700 (MST) Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi Doug I have very little time to look into this further but what we could do is open up an rxtx 3 devel branch in which a proof of concept could be worked on. It could be the proof of concept for a JSR others including Sun could look at/work on or parts of it could be recycled in a JSR. I'm working very hard on rxtx right now but it does not show. I'm looking at win64, mac intel/ppc, usb bluetooth and usb serial dongles. Some are going to be more tested than others but they are all on the plate. I'll be pushing all the fixes upstream when they are done. So I'm very busy in 2.1 but we could open a new branch. On Fri, 9 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > The deadlock issue is one that I have been thinking about > for some time now. > It seems to me that we need a resource manager that enables assignment > to a known process. > > The one thing that seems important about serial > ports is that two applications should not use the > same serial port at the same time. When this > happens, it throws an exception. > OK. > > The exception is a response to a lock condition that > arises from an unavailable resource. > > An abstract implementation (not born of native methods) might > assign a serial port to an application, until the > application releases it (or is forced to release > it by some kill mechanism). > > Some resources (like a registry) can be reused. > But others, like the serial port, > cannot. > > In the case of the serial port, we would like, I think, to > have the flyweight design pattern > without sharing and with object assignment tracking. > A means of breaking deadlock (like a leasing > mechanism) seems very useful, to me. > > My guess is that we can serialize the state of the Parametric Singleton Pattern > (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) > into the Preferences of the System. Preferences.systemRoot() might help > with that. When a resource is checked out, the lease time and owner are > listed. A thread that does this can be killed, but applications outside of Java > are problematic. > > There is a compelling problem here. It is not just serial ports. > Sound cards, cameras, microphones, files, tape drives, etc. All are consumed > resources that are assigned to an application (or > user) and deprive other applications, > or users, from use. > > What, if anything, should we do? At present we throw PortInUseExceptions. > Is that it? > Can we do better? > OK, the port is in use. Now what? > Do I have to be root to go remove lock files and kill applications? > Is there a better way? > > Thanks! > - Doug > >> I've just struck an issue using rxtx in a multi-threaded environment: >> >> If I have 3 threads trying to open *the same* >> comm-port I get a deadlock in >> CommPortIdentifier.open >> If I have just 2, it works fine - I get a >> PortInUseException which is nice and I can >> handle it. >> >> The 3 thread->deadlock thing is causing me issues. >> (Sample code below). >> >> This is from the java thread-dump >> >> Found one Java-level deadlock: >> ============================= >> "Thread-2": >> waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), >> which is held by "Thread-1" >> "Thread-1": >> waiting to lock monitor 0x0003e9cc (object >> 0x2450e108, a gnu.io.CommPortIdentifier ), >> which is held by "Thread-2" >> >> Java stack information for the threads listed above: >> =================================================== >> "Thread-2": >> at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) >> - waiting to lock <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> "Thread-1": >> at java.lang.Object.wait(Native Method) >> - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) >> - locked <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> >> >> (Apart from this, rxtx is working fantastically for us). >> >> I'm thinking I'll have to implement some sort of >> locking mechanism that *doesn't* use java >> synchronization to prevent this situation. >> (Which doesn't sound like a good idea to me). >> >> Any ideas? >> >> Thanks, >> >> Greg Hanna >> >> ============= RXTXLockTest.java ======================================== >> >> import gnu.io.CommPort; >> import gnu.io.CommPortIdentifier; >> >> /** >> * @author Greg Hanna >> * Minimal code to create a deadlock with rxtx in multithreaded open >> */ >> public class RXTXLockTest { >> ? >> ?public static void main(String[] args) { >> ?try { >> ?CommPortIdentifier cpiCom1 = >> CommPortIdentifier.getPortIdentifier ("COM14"); >> ?OpenThread t1 = new OpenThread (" one ", cpiCom1); >> ?OpenThread t2 = new OpenThread (" two ", cpiCom1); >> ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); >> ?t1.start(); >> ?t2.start(); >> ?t3.start(); // comment this out >> and it runs with (expected) PortInUseException >> ?} catch (Exception e) { >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> class OpenThread extends Thread { >> ?String name; >> ?CommPortIdentifier cpi; >> ?CommPort cp; >> ?public OpenThread (String name, CommPortIdentifier cpi) { >> ? this.name = name; >> ?this.cpi = cpi; >> ?System.out.println >> (System.currentTimeMillis() + name + " thread >> created"); >> ?} >> ?public void run () { >> ?try { >> ?System.out.println >> (System.currentTimeMillis() + name + " opening"); >> ?cp = cpi.open(name, 2000); >> ?System.out.println >> (System.currentTimeMillis() + name + " opened - >> sleeping"); >> ?sleep (2000); // do the serial comms with the device. >> ?System.out.println >> (System.currentTimeMillis() + name + " slept - >> closing"); >> ?cp.close(); >> ?System.out.println >> (System.currentTimeMillis() + name + " closed - >> exiting"); >> ?} catch (Exception e) { >> System.out.println ("Error in thread: " + name ); >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 mm at UDel.Edu Sat Mar 10 14:48:32 2007 From: mm at UDel.Edu (Mike Markowski) Date: Sat, 10 Mar 2007 16:48:32 -0500 Subject: [Rxtx] rxtx and Sun's comm api Message-ID: <45F327B0.2060004@udel.edu> Hi all, I joined the list a few days ago and apologize for what is likely a frequently asked question, though I haven't yet found it anywhere. I learned about rxtx.org through the readme on Sun's version 2 of their comms api. They give recommendations in that readme regarding how a better comms api should be written. Is this the aim of rxtx.org? I wrote an app on my linux box using the Sun comms api (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the fact that only linux and Solaris are supported. So I'm glad to find rxtx.org and am just reading up on how make the conversion so Windows users will be able to run the program as well. At the same time I'm just curious if rxtx.org and Sun are both heading in the same direction. Thanks for any background or historical info. Feel free to point me to any www pages if my googling has just completely missed the target! Thanks again, Mike From tjarvi at qbang.org Sat Mar 10 15:35:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 15:35:25 -0700 (MST) Subject: [Rxtx] rxtx and Sun's comm api In-Reply-To: <45F327B0.2060004@udel.edu> References: <45F327B0.2060004@udel.edu> Message-ID: On Sat, 10 Mar 2007, Mike Markowski wrote: > Hi all, > > I joined the list a few days ago and apologize for what is likely a > frequently asked question, though I haven't yet found it anywhere. I > learned about rxtx.org through the readme on Sun's version 2 of their > comms api. They give recommendations in that readme regarding how a > better comms api should be written. Is this the aim of rxtx.org? > > I wrote an app on my linux box using the Sun comms api > (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the > fact that only linux and Solaris are supported. So I'm glad to find > rxtx.org and am just reading up on how make the conversion so Windows > users will be able to run the program as well. At the same time I'm > just curious if rxtx.org and Sun are both heading in the same direction. > > Thanks for any background or historical info. Feel free to point me to > any www pages if my googling has just completely missed the target! > I do not have any news (good or bad) concerning RXTX and Sun working together but perhaps others here do. The main goal of RXTX is to expose POSIX termios interfaces to java users. The future support of javax.comm is questionable. We do not have resources for everything. gnu.io (RXTX 2.1) will be supported going forward and functions the same as CommAPI 2.0. If you have control of the source code you are working with, I would not advise using CommAPI 2.0 javax.comm. We do support CommAPI 2.0 javax.comm for older applications but I do not think that will last much longer for practical reasons. The download interest in CommAPI 2.0 javax.comm support is becomming negligible on this end. There has been discussion of a JSR effort but I do not know of any status change since it was mentioned. One problem with a JSR is that even a light weight process is going to be difficult for RXTX at this time. Maybe that will change in the future but then again it may not. For now, we are just going forward 'as is' in rxtx 2.1 with package gnu.io while trying as a secondary effort to backport the changes to rxtx 2.0 for javax.comm support for users that do not have a choice. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Mar 11 07:19:40 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 11 Mar 2007 08:19:40 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: Hi All, I have been a proponent of a JSR that makes use of RXTX. I have executed the proper agreements with Sun. At this point we are in the: Early Draft Review of Draft Specifications Stage. The best thing to do is to enter the quiet period and create a specification. The question of exactly how we, as a group, want to approach this problem, remains open. Typically, we should have both a specification and a reference implementation. Thus, it would be to our best advantage to have a nice, stable, cross platform RXTX distro that adheres to the groups specification. Now, from a specification standpoint, my personal view on the matter is that we create a series of interfaces, with nice documentation (or at least javadoc). Is this a good idea? Should we have a pure interface specification for the communication API? There are several issues, in my mind, which still weigh on us. Hot-pluggable dongles, long discovery process on pop-up ports, lack of uniformity on device names, lack of uniformity on locking, a precise understanding of how the SerialPortResourceManager works (or even if we should have one). The more questions we answer in our reference implementation, the better our specification will get. RXTX is a good working prototype, but, I don't know if that is what we want to use for a specification. Here is what I have for a CommPortInterface: */ public interface CommPortInterface { /** * @return a string representation of this port. */ String toString(); /** * Gets the name of the communications port. This name should correspond to * something the user can identify, like the label on the hardware. * @return name of the port */ String getName(); /** * @return an input stream that can be used to read data from the * communications port. If the port doesn't support reading data, this * method returns null. *

* The blocking behaviour of this input stream depends on the threshold * and timeout values, as shown below for a read buffer size of n * bytes: * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ThresholdTimeoutBlocking behaviour
StateValueStateValue
disableddisabledblock until data is available
enabledm bytesdisabledblock until min(m, n) bytes are available
disabledenabledt msblock for t ms or until data is available
enabledm bytesenabledt msblock for t ms or until min(m, n) bytes are * available
* @throws java.io.IOException */ InputStream getInputStream() throws IOException; /** * @return an output stream that can be used to send data to the * communications port. If the port doesn't support sending data, this * method returns null. * @throws java.io.IOException */ OutputStream getOutputStream() throws IOException; /** * Closes this communications port. * All PortOwnershipListeners will be? * notified of this change of ownership. Further method calls on this? * object will throw IllegalStateException. Further calls on the? * associated InputStream or OutputStream will throw IOException. *

* Close does not block. Undelivered data is discarded. Blocked read and? * write operations are aborted if the underlying operating systems? * supports an IO abort mechanism. To await the delivery of undelivered? * data call OutputStream.flush() or OutputStream.close() before calling? * Port.close(). */ void close(); /** * Enables receive threshold. * When the specified threshold number of bytes are retrieved, read will * return immediately. * * @param thresh the number of bytes in the input buffer * @throws gnu.io.UnsupportedCommOperationException * if receive threshold is * not supported by the driver * @see #disableReceiveThreshold */ void enableReceiveThreshold(int thresh) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive threshold. * * @see #enableReceiveThreshold */ void disableReceiveThreshold(); /** * @return true if receive threshold is enabled. * * @see #enableReceiveThreshold */ boolean isReceiveThresholdEnabled(); /** * @return the receive threshold value. If receive threshold is diabled * or not supported, this value is meaningless. * * @see #enableReceiveThreshold */ int getReceiveThreshold(); /** * Enables receive timeout. * When the specified number of milliseconds have elapsed, read will * return immediately. * * @param rcvTimeout the number of milliseconds to block for * @throws gnu.io.UnsupportedCommOperationException * if receive timeout is * not supported by the driver * @see #disableReceiveTimeout */ void enableReceiveTimeout(int rcvTimeout) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive timeout. * * @see #enableReceiveTimeout */ void disableReceiveTimeout(); /** * @return true if receive timeout is enabled. * * @see #enableReceiveTimeout */ boolean isReceiveTimeoutEnabled(); /** * @return the receive timeout value. If receive timeout is diabled * or not supported, this value is meaningless. * * @see #enableReceiveTimeout */ int getReceiveTimeout(); /** * Enables receive framing. * The supplied byte value in the input suggests the end of the received * frame, and read returns immediately. Only the low 8 bits of the * supplied value are significant. * * @param framingByte the frame delimiter * @throws gnu.io.UnsupportedCommOperationException * if receive framing is * not supported by the driver * @see #disableReceiveFraming */ void enableReceiveFraming(int framingByte) throws UnsupportedCommOperationException; /** * Disables receive framing. * * @see #enableReceiveFraming */ void disableReceiveFraming(); /** * @return true if receive framing is enabled. * * @see #enableReceiveFraming */ boolean isReceiveFramingEnabled(); /** * @return true if receive framing byte. If receive framing is diabled * or not supported, this value is meaningless. * * @see #enableReceiveFraming */ int getReceiveFramingByte(); /** * Sets the input buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setInputBufferSize(int size); /** * @return the input buffer size. * The driver may choose not to report correct values. */ int getInputBufferSize(); /** * Sets the output buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setOutputBufferSize(int size); /** * @return the output buffer size. * The driver may choose not to report correct values. */ int getOutputBufferSize(); } What do you think of that? Note the wishy washy nature of the spec: The driver may choose to ignore this method. Is that good enough for us? Thanks! - Doug From ra85551 at gmail.com Sun Mar 11 08:44:45 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Sun, 11 Mar 2007 17:44:45 +0300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hello, world! I am writing application that communicates with modem via AT commands. My OS is Linux Kubuntu Feisty Herd, to ensure that my application will run properly under Windows XP I installed VMWare server. When I tried to send AT command and evaluate modem answer under WinXP @ VMWare server, I actually didn't receive anything. I think that VM settings are right, because I do can communicate with modem by using standard HyperTerminall as well as I can do on native Windows. So, why RXTX doesn't work under VM, but works under Linux and pure Windows XP (i tested it there) well? The send/receive method code follows. private String sendATCommand(String command, final String waitFor, final boolean isRegex, boolean isAddCRLF, long timeout) throws BeaconConnectException { final long POLL_PERIOD = 100; final int BUFFER_SIZE = 512; final byte[] buffer = new byte[BUFFER_SIZE]; final InputStream serialInput; final OutputStream serialOutput; try { serialInput = serialPort.getInputStream(); if (command != null) { serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } } catch (IOException e) { throw new MyException("serial I/O error"); } TimerTask task = new TimerTask() { int offset = 0; int bytesRead; public synchronized void run() { try { if (serialInput.available() > 0) { bytesRead = serialInput.read(buffer, offset, BUFFER_SIZE - offset); } else { return; } } catch (IOException e) { // do nothing - maybe next time we'll read something } offset += bytesRead; if (waitFor != null) { String temporary = new String(buffer, 0, offset).trim(); if (isRegex && temporary.matches(waitFor) || temporary.contains(waitFor)) { cancel(); notify(); } } } }; Timer timer = new Timer(); timer.schedule(task, POLL_PERIOD, POLL_PERIOD); synchronized (task) { try { task.wait(timeout); task.cancel(); } catch (InterruptedException e) { } } //Cut off leading and trailing CRs, LFs and zeroes String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); System.out.println(response); return response; } -- Pavel Parkhomenko From tjarvi at qbang.org Sun Mar 11 11:48:22 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:48:22 -0600 (MDT) Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: On Sun, 11 Mar 2007, Pavel Parkhomenko wrote: > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. > > private String sendATCommand(String command, final String waitFor, > final boolean isRegex, boolean isAddCRLF, long timeout) > throws BeaconConnectException > { > final long POLL_PERIOD = 100; > final int BUFFER_SIZE = 512; > final byte[] buffer = new byte[BUFFER_SIZE]; > final InputStream serialInput; > final OutputStream serialOutput; > try > { > serialInput = serialPort.getInputStream(); > if (command != null) > { > serialOutput = serialPort.getOutputStream(); > if (isAddCRLF) > { > command += "\r\n"; > } > System.out.println(command); > serialOutput.write(command.getBytes()); > } > } > catch (IOException e) > { > throw new MyException("serial I/O error"); > } > > TimerTask task = new TimerTask() > { > int offset = 0; > int bytesRead; > public synchronized void run() > { > try > { > if (serialInput.available() > 0) > { > bytesRead = serialInput.read(buffer, offset, > BUFFER_SIZE - offset); > } > else > { > return; > } > } > catch (IOException e) > { > // do nothing - maybe next time we'll read something > } > offset += bytesRead; > if (waitFor != null) > { > String temporary = new String(buffer, 0, offset).trim(); > if (isRegex && temporary.matches(waitFor) || > temporary.contains(waitFor)) > { > cancel(); > notify(); > } > } > } > }; > > Timer timer = new Timer(); > timer.schedule(task, POLL_PERIOD, POLL_PERIOD); > synchronized (task) { > try > { > task.wait(timeout); > task.cancel(); > } > catch (InterruptedException e) > { > } > } > //Cut off leading and trailing CRs, LFs and zeroes > String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); > System.out.println(response); > return response; > } > > > Hi Pavel VMWare should not be a problem. I've used it in the past - though not with a modem. Make sure nothing else is using the modem. Then look in the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an example that should work. Note that modems could care less what OS is on top. If you are trying to match new lines to the OS and sending it to the mode for AT commands, thats probably a mistake. Also it would not hurt to print out the individual bytes that you are sending to make sure they did not get mangled along the path. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 11:55:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:55:48 -0600 (MDT) Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: On Sun, 11 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > I have been a proponent of a JSR that makes > use of RXTX. I have executed the proper agreements with Sun. > > At this point we are in the: > Early Draft Review of Draft Specifications Stage. > > The best thing to do is to enter the quiet period and create > a specification. The question of exactly how we, as a group, > want to approach this problem, remains open. > > Typically, we should have both a specification and a reference > implementation. Thus, it would be to our best advantage to have > a nice, stable, cross platform RXTX distro that adheres to the > groups specification. > > Now, from a specification standpoint, my personal view on the matter is > that we create a series of interfaces, with nice documentation (or at least > javadoc). > > Is this a good idea? Should we have a pure interface specification for > the communication API? > > There are several issues, in my mind, which still weigh on us. > Hot-pluggable dongles, long discovery process on pop-up ports, > lack of uniformity on device names, lack of uniformity on locking, > a precise understanding of how the SerialPortResourceManager > works (or even if we should have one). > > The more questions we answer in our reference implementation, the > better our specification will get. RXTX is a good working prototype, > but, I don't know if that is what we want to use for a specification. > > Here is what I have for a CommPortInterface: > */ > public interface CommPortInterface { Hi Doug, I can start going through the method interfaces later this week and giving feedback. I would suggest that the JSR should not be too generic in nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel drivers that intend to look like EIA232 ports at the kernel driver level. some ideas: EIA232PortInterface TermiosInterface SerialPortInterface Something that differentiates this from thing like USB, I2C, ... which should not have to deal with legacy serial claiming to be the comm api. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 12:52:19 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 12:52:19 -0600 (MDT) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: No news is good news with these posts. I'll start the process of pinging legal a week from Monday on my end if nobody has objections to the proposal. I just want to make sure everyone has time to raise objections. Obviously, anyone can fork from a previous version if they don't like the new license. I suspect we can avoid that though. On Sun, 4 Mar 2007, Trent Jarvi wrote: > > For those that are wondering what is going on here, this > next bit is the meat of the changes. We agreed a long time > ago to put this disclaimer in. We did a so so job. It was > in rxtx 2.0, not well written, ... So some groups using > rxtx that would like to ship rxtx so users don't need to > download, install, go to the mail-list to find why it failed, > ... Then their legal teams tell them section 5 paragraph 2 > is a show stopper. > > That was never the intent. > > > Now going through what remains... > >> and might need a (TM) suffix to make Sun happy. > > Added disclaimer at the ended 'all trademarks belong...' > >> * Line #15ff - static vs. dynamic linking - you did >> not transcribe the text from the "controlled >> interface exception" when writing this text - and >> this was good so, because these terms originally >> refer to the GPL rather than the LGPL. I think though, >> that these 4 lines are the most important ones and >> should thus be really really clear. I hope that I >> meet your original intent with the following >> suggestions: >> 1.) Instead of "A program.." it would be better to >> say "An exectuable.." in order to be closer to >> the LGPL text. > > OK. As you can see I was trying to adjust GNU text there > for the LGPL. > >> 2.) It would be better to say .. "by being dynamically >> linked with it" to clearly indicate that dynamic >> linking is meant. The matter of compilation is >> already covered by the LGPL so mentioning it again >> just leads to confusion. > > used dynamically linked terminology. > >> 3.) It would be better to say .. "is considered a >> work that uses the library in contrast to section >> 5 of the LGPL, so the terms of the LGPL do not >> apply to the resulting executable". > > I tried to address this more upfront with an intent statement. > Let me know if you have problems with it. I also tried to > make it a little more clear what was derived from the GNU > solution by moving the link location closer to GNU's suggestion. > >> >> Note that LGPL section 5 says: ..."is called a >> "work that uses the Library". Such a work, in isolation, >> is not a derivative work of the Library, and therefore >> falls outside the scope of this License." >> The next paragraph of the LGPL is exactly the problematic >> one that I hope is clarified by the exception terms you >> give. >> > > Thats the intent. Here is the combined fixes. Note that only the > material in /*-- --*/ is being touched. The new GPL license is > there but unmodified. > > > ------------------------ begin proposed new license ------------------- > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Lesser General Public > | License as published by the Free Software Foundation; either > | version 2.1 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Lesser General Public License for more details. > | > | An executable that contains no derivative of any portion of RXTX, but > | is designed to work with RXTX by being dynamically linked with it, > | is considered a "work that uses the Library" subject to the terms and > | conditions of the GNU Lesser General Public License. > | > | The following has been added to the RXTX License to remove > | any confusion about linking to RXTX. We want to allow in part what > | section 5, paragraph 2 of the LGPL does not permit in the special > | case of linking over a controlled interface. The intent is to add a > | Java Specification Request or standards body defined interface in the > | future as another exception but one is not currently available. > | > | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface > | > | As a special exception, the copyright holders of RXTX give you > | permission to link RXTX with independent modules that communicate with > | RXTX solely through the Sun Microsytems CommAPI interface version 2, > | regardless of the license terms of these independent modules, and to copy > | and distribute the resulting combined work under terms of your choice, > | provided that every copy of the combined work is accompanied by a complete > | copy of the source code of RXTX (the version of RXTX used to produce the > | combined work), being distributed under the terms of the GNU Lesser General > | Public License plus this exception. An independent module is a > | module which is not derived from or based on RXTX. > | > | Note that people who make modified versions of RXTX are not obligated > | to grant this special exception for their modified versions; it is > | their choice whether to do so. The GNU Lesser General Public License > | gives permission to release a modified version without this exception; this > | exception also makes it possible to release a modified version which > | carries forward this exception. > | > | You should have received a copy of the GNU Lesser General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > | All trademarks belong to their respective owners. > --------------------------------------------------------------------------*/ > > The original GNU Lesser General Public License Follows. > > > GNU LESSER GENERAL PUBLIC LICENSE > Version 2.1, February 1999 > > Copyright (C) 1991, 1999 Free Software Foundation, Inc. > 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > Everyone is permitted to copy and distribute verbatim copies > of this license document, but changing it is not allowed. > > [This is the first released version of the Lesser GPL. It also counts > as the successor of the GNU Library Public License, version 2, hence > the version number 2.1.] > > Preamble > > The licenses for most software are designed to take away your > freedom to share and change it. By contrast, the GNU General Public > Licenses are intended to guarantee your freedom to share and change > free software--to make sure the software is free for all its users. > > This license, the Lesser General Public License, applies to some > specially designated software packages--typically libraries--of the > Free Software Foundation and other authors who decide to use it. You > can use it too, but we suggest you first think carefully about whether > this license or the ordinary General Public License is the better > strategy to use in any particular case, based on the explanations below. > > When we speak of free software, we are referring to freedom of use, > not price. Our General Public Licenses are designed to make sure that > you have the freedom to distribute copies of free software (and charge > for this service if you wish); that you receive source code or can get > it if you want it; that you can change the software and use pieces of > it in new free programs; and that you are informed that you can do > these things. > > To protect your rights, we need to make restrictions that forbid > distributors to deny you these rights or to ask you to surrender these > rights. These restrictions translate to certain responsibilities for > you if you distribute copies of the library or if you modify it. > > For example, if you distribute copies of the library, whether gratis > or for a fee, you must give the recipients all the rights that we gave > you. You must make sure that they, too, receive or can get the source > code. If you link other code with the library, you must provide > complete object files to the recipients, so that they can relink them > with the library after making changes to the library and recompiling > it. And you must show them these terms so they know their rights. > > We protect your rights with a two-step method: (1) we copyright the > library, and (2) we offer you this license, which gives you legal > permission to copy, distribute and/or modify the library. > > To protect each distributor, we want to make it very clear that > there is no warranty for the free library. Also, if the library is > modified by someone else and passed on, the recipients should know > that what they have is not the original version, so that the original > author's reputation will not be affected by problems that might be > introduced by others. > > Finally, software patents pose a constant threat to the existence of > any free program. We wish to make sure that a company cannot > effectively restrict the users of a free program by obtaining a > restrictive license from a patent holder. Therefore, we insist that > any patent license obtained for a version of the library must be > consistent with the full freedom of use specified in this license. > > Most GNU software, including some libraries, is covered by the > ordinary GNU General Public License. This license, the GNU Lesser > General Public License, applies to certain designated libraries, and > is quite different from the ordinary General Public License. We use > this license for certain libraries in order to permit linking those > libraries into non-free programs. > > When a program is linked with a library, whether statically or using > a shared library, the combination of the two is legally speaking a > combined work, a derivative of the original library. The ordinary > General Public License therefore permits such linking only if the > entire combination fits its criteria of freedom. The Lesser General > Public License permits more lax criteria for linking other code with > the library. > > We call this license the "Lesser" General Public License because it > does Less to protect the user's freedom than the ordinary General > Public License. It also provides other free software developers Less > of an advantage over competing non-free programs. These disadvantages > are the reason we use the ordinary General Public License for many > libraries. However, the Lesser license provides advantages in certain > special circumstances. > > For example, on rare occasions, there may be a special need to > encourage the widest possible use of a certain library, so that it becomes > a de-facto standard. To achieve this, non-free programs must be > allowed to use the library. A more frequent case is that a free > library does the same job as widely used non-free libraries. In this > case, there is little to gain by limiting the free library to free > software only, so we use the Lesser General Public License. > > In other cases, permission to use a particular library in non-free > programs enables a greater number of people to use a large body of > free software. For example, permission to use the GNU C Library in > non-free programs enables many more people to use the whole GNU > operating system, as well as its variant, the GNU/Linux operating > system. > > Although the Lesser General Public License is Less protective of the > users' freedom, it does ensure that the user of a program that is > linked with the Library has the freedom and the wherewithal to run > that program using a modified version of the Library. > > The precise terms and conditions for copying, distribution and > modification follow. Pay close attention to the difference between a > "work based on the library" and a "work that uses the library". The > former contains code derived from the library, whereas the latter must > be combined with the library in order to run. > > GNU LESSER GENERAL PUBLIC LICENSE > TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION > > 0. This License Agreement applies to any software library or other > program which contains a notice placed by the copyright holder or > other authorized party saying it may be distributed under the terms of > this Lesser General Public License (also called "this License"). > Each licensee is addressed as "you". > > A "library" means a collection of software functions and/or data > prepared so as to be conveniently linked with application programs > (which use some of those functions and data) to form executables. > > The "Library", below, refers to any such software library or work > which has been distributed under these terms. A "work based on the > Library" means either the Library or any derivative work under > copyright law: that is to say, a work containing the Library or a > portion of it, either verbatim or with modifications and/or translated > straightforwardly into another language. (Hereinafter, translation is > included without limitation in the term "modification".) > > "Source code" for a work means the preferred form of the work for > making modifications to it. For a library, complete source code means > all the source code for all modules it contains, plus any associated > interface definition files, plus the scripts used to control compilation > and installation of the library. > > Activities other than copying, distribution and modification are not > covered by this License; they are outside its scope. The act of > running a program using the Library is not restricted, and output from > such a program is covered only if its contents constitute a work based > on the Library (independent of the use of the Library in a tool for > writing it). Whether that is true depends on what the Library does > and what the program that uses the Library does. > > 1. You may copy and distribute verbatim copies of the Library's > complete source code as you receive it, in any medium, provided that > you conspicuously and appropriately publish on each copy an > appropriate copyright notice and disclaimer of warranty; keep intact > all the notices that refer to this License and to the absence of any > warranty; and distribute a copy of this License along with the > Library. > > You may charge a fee for the physical act of transferring a copy, > and you may at your option offer warranty protection in exchange for a > fee. > > 2. You may modify your copy or copies of the Library or any portion > of it, thus forming a work based on the Library, and copy and > distribute such modifications or work under the terms of Section 1 > above, provided that you also meet all of these conditions: > > a) The modified work must itself be a software library. > > b) You must cause the files modified to carry prominent notices > stating that you changed the files and the date of any change. > > c) You must cause the whole of the work to be licensed at no > charge to all third parties under the terms of this License. > > d) If a facility in the modified Library refers to a function or a > table of data to be supplied by an application program that uses > the facility, other than as an argument passed when the facility > is invoked, then you must make a good faith effort to ensure that, > in the event an application does not supply such function or > table, the facility still operates, and performs whatever part of > its purpose remains meaningful. > > (For example, a function in a library to compute square roots has > a purpose that is entirely well-defined independent of the > application. Therefore, Subsection 2d requires that any > application-supplied function or table used by this function must > be optional: if the application does not supply it, the square > root function must still compute square roots.) > > These requirements apply to the modified work as a whole. If > identifiable sections of that work are not derived from the Library, > and can be reasonably considered independent and separate works in > themselves, then this License, and its terms, do not apply to those > sections when you distribute them as separate works. But when you > distribute the same sections as part of a whole which is a work based > on the Library, the distribution of the whole must be on the terms of > this License, whose permissions for other licensees extend to the > entire whole, and thus to each and every part regardless of who wrote > it. > > Thus, it is not the intent of this section to claim rights or contest > your rights to work written entirely by you; rather, the intent is to > exercise the right to control the distribution of derivative or > collective works based on the Library. > > In addition, mere aggregation of another work not based on the Library > with the Library (or with a work based on the Library) on a volume of > a storage or distribution medium does not bring the other work under > the scope of this License. > > 3. You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. To do > this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version 2, > instead of to this License. (If a newer version than version 2 of the > ordinary GNU General Public License has appeared, then you can specify > that version instead if you wish.) Do not make any other change in > these notices. > > Once this change is made in a given copy, it is irreversible for > that copy, so the ordinary GNU General Public License applies to all > subsequent copies and derivative works made from that copy. > > This option is useful when you wish to copy part of the code of > the Library into a program that is not a library. > > 4. You may copy and distribute the Library (or a portion or > derivative of it, under Section 2) in object code or executable form > under the terms of Sections 1 and 2 above provided that you accompany > it with the complete corresponding machine-readable source code, which > must be distributed under the terms of Sections 1 and 2 above on a > medium customarily used for software interchange. > > If distribution of object code is made by offering access to copy > from a designated place, then offering equivalent access to copy the > source code from the same place satisfies the requirement to > distribute the source code, even though third parties are not > compelled to copy the source along with the object code. > > 5. A program that contains no derivative of any portion of the > Library, but is designed to work with the Library by being compiled or > linked with it, is called a "work that uses the Library". Such a > work, in isolation, is not a derivative work of the Library, and > therefore falls outside the scope of this License. > > However, linking a "work that uses the Library" with the Library > creates an executable that is a derivative of the Library (because it > contains portions of the Library), rather than a "work that uses the > library". The executable is therefore covered by this License. > Section 6 states terms for distribution of such executables. > > When a "work that uses the Library" uses material from a header file > that is part of the Library, the object code for the work may be a > derivative work of the Library even though the source code is not. > Whether this is true is especially significant if the work can be > linked without the Library, or if the work is itself a library. The > threshold for this to be true is not precisely defined by law. > > If such an object file uses only numerical parameters, data > structure layouts and accessors, and small macros and small inline > functions (ten lines or less in length), then the use of the object > file is unrestricted, regardless of whether it is legally a derivative > work. (Executables containing this object code plus portions of the > Library will still fall under Section 6.) > > Otherwise, if the work is a derivative of the Library, you may > distribute the object code for the work under the terms of Section 6. > Any executables containing that work also fall under Section 6, > whether or not they are linked directly with the Library itself. > > 6. As an exception to the Sections above, you may also combine or > link a "work that uses the Library" with the Library to produce a > work containing portions of the Library, and distribute that work > under terms of your choice, provided that the terms permit > modification of the work for the customer's own use and reverse > engineering for debugging such modifications. > > You must give prominent notice with each copy of the work that the > Library is used in it and that the Library and its use are covered by > this License. You must supply a copy of this License. If the work > during execution displays copyright notices, you must include the > copyright notice for the Library among them, as well as a reference > directing the user to the copy of this License. Also, you must do one > of these things: > > a) Accompany the work with the complete corresponding > machine-readable source code for the Library including whatever > changes were used in the work (which must be distributed under > Sections 1 and 2 above); and, if the work is an executable linked > with the Library, with the complete machine-readable "work that > uses the Library", as object code and/or source code, so that the > user can modify the Library and then relink to produce a modified > executable containing the modified Library. (It is understood > that the user who changes the contents of definitions files in the > Library will not necessarily be able to recompile the application > to use the modified definitions.) > > b) Use a suitable shared library mechanism for linking with the > Library. A suitable mechanism is one that (1) uses at run time a > copy of the library already present on the user's computer system, > rather than copying library functions into the executable, and (2) > will operate properly with a modified version of the library, if > the user installs one, as long as the modified version is > interface-compatible with the version that the work was made with. > > c) Accompany the work with a written offer, valid for at > least three years, to give the same user the materials > specified in Subsection 6a, above, for a charge no more > than the cost of performing this distribution. > > d) If distribution of the work is made by offering access to copy > from a designated place, offer equivalent access to copy the above > specified materials from the same place. > > e) Verify that the user has already received a copy of these > materials or that you have already sent this user a copy. > > For an executable, the required form of the "work that uses the > Library" must include any data and utility programs needed for > reproducing the executable from it. However, as a special exception, > the materials to be distributed need not include anything that is > normally distributed (in either source or binary form) with the major > components (compiler, kernel, and so on) of the operating system on > which the executable runs, unless that component itself accompanies > the executable. > > It may happen that this requirement contradicts the license > restrictions of other proprietary libraries that do not normally > accompany the operating system. Such a contradiction means you cannot > use both them and the Library together in an executable that you > distribute. > > 7. You may place library facilities that are a work based on the > Library side-by-side in a single library together with other library > facilities not covered by this License, and distribute such a combined > library, provided that the separate distribution of the work based on > the Library and of the other library facilities is otherwise > permitted, and provided that you do these two things: > > a) Accompany the combined library with a copy of the same work > based on the Library, uncombined with any other library > facilities. This must be distributed under the terms of the > Sections above. > > b) Give prominent notice with the combined library of the fact > that part of it is a work based on the Library, and explaining > where to find the accompanying uncombined form of the same work. > > 8. You may not copy, modify, sublicense, link with, or distribute > the Library except as expressly provided under this License. Any > attempt otherwise to copy, modify, sublicense, link with, or > distribute the Library is void, and will automatically terminate your > rights under this License. However, parties who have received copies, > or rights, from you under this License will not have their licenses > terminated so long as such parties remain in full compliance. > > 9. You are not required to accept this License, since you have not > signed it. However, nothing else grants you permission to modify or > distribute the Library or its derivative works. These actions are > prohibited by law if you do not accept this License. Therefore, by > modifying or distributing the Library (or any work based on the > Library), you indicate your acceptance of this License to do so, and > all its terms and conditions for copying, distributing or modifying > the Library or works based on it. > > 10. Each time you redistribute the Library (or any work based on the > Library), the recipient automatically receives a license from the > original licensor to copy, distribute, link with or modify the Library > subject to these terms and conditions. You may not impose any further > restrictions on the recipients' exercise of the rights granted herein. > You are not responsible for enforcing compliance by third parties with > this License. > > 11. If, as a consequence of a court judgment or allegation of patent > infringement or for any other reason (not limited to patent issues), > conditions are imposed on you (whether by court order, agreement or > otherwise) that contradict the conditions of this License, they do not > excuse you from the conditions of this License. If you cannot > distribute so as to satisfy simultaneously your obligations under this > License and any other pertinent obligations, then as a consequence you > may not distribute the Library at all. For example, if a patent > license would not permit royalty-free redistribution of the Library by > all those who receive copies directly or indirectly through you, then > the only way you could satisfy both it and this License would be to > refrain entirely from distribution of the Library. > > If any portion of this section is held invalid or unenforceable under any > particular circumstance, the balance of the section is intended to apply, > and the section as a whole is intended to apply in other circumstances. > > It is not the purpose of this section to induce you to infringe any > patents or other property right claims or to contest validity of any > such claims; this section has the sole purpose of protecting the > integrity of the free software distribution system which is > implemented by public license practices. Many people have made > generous contributions to the wide range of software distributed > through that system in reliance on consistent application of that > system; it is up to the author/donor to decide if he or she is willing > to distribute software through any other system and a licensee cannot > impose that choice. > > This section is intended to make thoroughly clear what is believed to > be a consequence of the rest of this License. > > 12. If the distribution and/or use of the Library is restricted in > certain countries either by patents or by copyrighted interfaces, the > original copyright holder who places the Library under this License may add > an explicit geographical distribution limitation excluding those countries, > so that distribution is permitted only in or among countries not thus > excluded. In such case, this License incorporates the limitation as if > written in the body of this License. > > 13. The Free Software Foundation may publish revised and/or new > versions of the Lesser General Public License from time to time. > Such new versions will be similar in spirit to the present version, > but may differ in detail to address new problems or concerns. > > Each version is given a distinguishing version number. If the Library > specifies a version number of this License which applies to it and > "any later version", you have the option of following the terms and > conditions either of that version or of any later version published by > the Free Software Foundation. If the Library does not specify a > license version number, you may choose any version ever published by > the Free Software Foundation. > > 14. If you wish to incorporate parts of the Library into other free > programs whose distribution conditions are incompatible with these, > write to the author to ask for permission. For software which is > copyrighted by the Free Software Foundation, write to the Free > Software Foundation; we sometimes make exceptions for this. Our > decision will be guided by the two goals of preserving the free status > of all derivatives of our free software and of promoting the sharing > and reuse of software generally. > > NO WARRANTY > > 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO > WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. > EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR > OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY > KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE > IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE > LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME > THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. > > 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN > WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY > AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU > FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR > CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE > LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING > RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A > FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF > SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH > DAMAGES. > > END OF TERMS AND CONDITIONS > > How to Apply These Terms to Your New Libraries > > If you develop a new library, and you want it to be of the greatest > possible use to the public, we recommend making it free software that > everyone can redistribute and change. You can do so by permitting > redistribution under these terms (or, alternatively, under the terms of the > ordinary General Public License). > > To apply these terms, attach the following notices to the library. It is > safest to attach them to the start of each source file to most effectively > convey the exclusion of warranty; and each file should have at least the > "copyright" line and a pointer to where the full notice is found. > > > Copyright (C) > > This library is free software; you can redistribute it and/or > modify it under the terms of the GNU Lesser General Public > License as published by the Free Software Foundation; either > version 2.1 of the License, or (at your option) any later version. > > This library is distributed in the hope that it will be useful, > but WITHOUT ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > Lesser General Public License for more details. > > You should have received a copy of the GNU Lesser General Public > License along with this library; if not, write to the Free Software > Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > > Also add information on how to contact you by electronic and paper mail. > > You should also get your employer (if you work as a programmer) or your > school, if any, to sign a "copyright disclaimer" for the library, if > necessary. Here is a sample; alter the names: > > Yoyodyne, Inc., hereby disclaims all copyright interest in the > library `Frob' (a library for tweaking knobs) written by James Random Hacker. > > , 1 April 1990 > Ty Coon, President of Vice > > That's all there is to it! > ------------------------ end of proposed license ------------------ > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From gjhanna at gmail.com Sun Mar 11 14:21:17 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Mon, 12 Mar 2007 09:21:17 +1300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hi Pavel, We are using RXTX under VMWare server in production, quite satisfactorily. We're using Red Hat Enterprise Server 4, and ... Whatever the "enterprise" VMWare product is. Regards, Greg H > Subject: [Rxtx] RXTX under VMWare server > To: rxtx at qbang.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. [ ... snip ... ] -- Pavel Parkhomenko -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070311/4cebb6f9/attachment-0083.html From gergg at cox.net Sun Mar 11 23:39:19 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 12 Mar 2007 00:39:19 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: <45F4E787.6050502@cox.net> Trent Jarvi wrote: > I can start going through the method interfaces later this week and giving > feedback. I would suggest that the JSR should not be too generic in > nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel > drivers that intend to look like EIA232 ports at the kernel driver level. > > some ideas: > > EIA232PortInterface > TermiosInterface > SerialPortInterface > > Something that differentiates this from thing like USB, I2C, ... which > should not have to deal with legacy serial claiming to be the comm api. I'm going to throw out a suggestion, which I am mostly serious about. What would happen if we took the appropriate bits of the J2ME connector API, and just used that as the new COMM API so that finally JSE and JME had a common foundation for these kinds of things? Gregg Wonderly From ra85551 at gmail.com Mon Mar 12 09:08:37 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Mon, 12 Mar 2007 18:08:37 +0300 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Should any application use the modem, HyperTerminal won't be able to talk to the modem. But it actually can send and receive AT comands, while my application cannot :-( > Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Thansk for the reference. I examined that example and found that there's no significant differences between my read/write implementation and that one, except that SimpleSnuV1 listens for serialEvent's, but not for sake of data retrieval, just for printing them out - I don't know why ;-) > Note that modems could care less what OS is on top. If you are trying to > match new lines to the OS and sending it to the mode for AT commands, > thats probably a mistake. I do send strings to serial port, not to OS, and do try to get answers back. If it is the mistake, what's the right way? > Also it would not hurt to print out the > individual bytes that you are sending to make sure they did not get > mangled along the path. Yeah, I am printing these bytes before doing write, but it means that I only see what I intend to write. How can I ensure that these bytes have gone out of the box and reached my modem? BTW, I found that my send/receive method is complex enough, so I've rewritten it. Please, see the following code and point any mistakes, because I don't know where can they remain yet. private static final int LARGE_TIMEOUT = 15000; private static final int SMALL_TIMEOUT = 500; ... private String sendATCommand(String command, String waitFor, boolean isRegex, boolean isAddCRLF) throws BeaconConnectException { byte[] buffer = new byte[512]; int offset; String result = ""; try { if (waitFor != null) { serialPort.enableReceiveTimeout(LARGE_TIMEOUT); } else { serialPort.enableReceiveTimeout(SMALL_TIMEOUT); } if (command != null) { OutputStream serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } offset = 0; InputStream serialInput = serialPort.getInputStream(); while (serialInput.available() != -1) { int bytesRead = serialInput.read(buffer, offset, buffer.length - offset); if (bytesRead == 0) { break; } offset += bytesRead; result = new String(buffer, 0, offset).trim(); if (waitFor != null) { System.out.println(result); if (isRegex && result.matches(waitFor) || result.contains(waitFor)) { break; } } } } catch (UnsupportedCommOperationException e) { throw new MyException("unsupported operation"); } catch (IOException e) { throw new MytException("serial I/O error"); } return result; } -- Pavel Parkhomenko From clayno at hotpop.com Thu Mar 15 02:47:34 2007 From: clayno at hotpop.com (Christopher Layno) Date: Thu, 15 Mar 2007 16:47:34 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi, we're using the latest release of rxtx (2.1-7r2) for our system that has two applications using the library. one application sends requests to the modem while the other simply checks the modem status. we deployed our system on a pentium machine with red hat linux 9.0 installed. now the problem arises when these two applications try to access the same modem at the same time. one of them will eventually have to throw the PortInUseException as shown below: 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException gnu.io.PortInUseException: root PID = 743 Program = java root PID = 743 Program = java root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) this was expected. what we didn't expect though was that if we repeat the scenario 5 times, always 5 times, the application would also throw a VM error: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4473CD21 Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so Current Java thread: at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) - locked <0x44cfd4c8> (a gnu.io.CommPortIdentifier) at ************ at ************ - locked <0x4476a468> (a **********) at ************ at ************ at ************ at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java :261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages( TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run( TCPTransport.java:701) at java.lang.Thread.run(Thread.java:534) note: i replaced some sensitive data with asterisks our team has looked everywhere on the internet, including your mail archives, for a solution to this problem but to no avail. i really hope you could help us out on this one. thanks in advance! best regards, chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070315/1936460a/attachment-0080.html From tjarvi at qbang.org Fri Mar 16 04:30:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 04:30:25 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: On Thu, 15 Mar 2007, Christopher Layno wrote: > hi, > > we're using the latest release of rxtx (2.1-7r2) for our system that has two > applications using the library. one application sends requests to the modem > while the other simply checks the modem status. we deployed our system on a > pentium machine with red hat linux 9.0 installed. > > now the problem arises when these two applications try to access the same > modem at the same time. one of them will eventually have to throw the > PortInUseException as shown below: > > 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException > gnu.io.PortInUseException: root PID = 743 Program = java root PID = > 743 Program = java root PID = 743 Program = ??? root PID = 743 Program > = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root > PID = 743 Program = ??? root PID = 743 Program = ??? > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > > this was expected. what we didn't expect though was that if we repeat the > scenario 5 times, always 5 times, the application would also throw a VM > error: > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x4473CD21 > Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 > Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so > > Current Java thread: > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) Hi Chris The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. The code is originally by Werner Almesberger. He gave us permission to use it in rxtx. You might look at what has changed since 1998 in his fuser application. Or you can just do like other OSs and do the following in fuserImp.c JNIEXPORT jstring JNICALL Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv *env, jobject obj, jstring arg) { return (*env)->NewStringUTF(env, "Unknown Application"); } It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. -- Trent Jarvi tjarvi at qang.org From Adrien.TOS at ingenico.com Fri Mar 16 05:11:12 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Fri, 16 Mar 2007 12:11:12 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903CBC312@frsnprexc1.usr.ingenico.loc> Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070316/972ab214/attachment-0079.html From joachim at buechse.de Fri Mar 16 05:13:24 2007 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 16 Mar 2007 12:13:24 +0100 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. From tjarvi at qbang.org Fri Mar 16 16:36:29 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 16:36:29 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Fri Mar 16 16:02:23 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 16 Mar 2007 18:02:23 -0400 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Not all platforms are Unix based. Also mixing native library usage and command-line calls is not an elegant solution, IMHO. One or the other, but not both. Andre On 16-Mar-07, at 07:13 , Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is > trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We >> only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From clayno at hotpop.com Sun Mar 18 22:17:28 2007 From: clayno at hotpop.com (Christopher Layno) Date: Mon, 19 Mar 2007 12:17:28 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi everyone, thank you so much for your replies. they were really helpful. anyway, before i sent the email, my team was already implementing a temporary solution by using joachim's suggestion. we invoked a lsof command from our java code although i share the same concern with trent and andre-john about portability issues. that's why i said it's just temporary. my superiors have yet to approve our bug fix. so my question now is this: is recompiling the rxtx source code the only way to solve this problem? because if it's the only solution, then i think my superiors would rather have a new release from the rxtx community itself that fixes this bug(?) rather than have my team recompile the source code. best regards, chris Trent Jarvi wrote: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. ... It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070318/237463b2/attachment-0076.html From tjarvi at qbang.org Mon Mar 19 16:20:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Mar 2007 16:20:52 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: Hi Chris I can compile a new version after the 21st if you do not feel comfortable doing so. Please send me an email reminder off-line then. On Mon, 19 Mar 2007, Christopher Layno wrote: > hi everyone, > > thank you so much for your replies. they were really helpful. > > anyway, before i sent the email, my team was already implementing a > temporary solution by using joachim's suggestion. > we invoked a lsof command from our java code although i share the same > concern with trent and andre-john about > portability issues. that's why i said it's just temporary. my superiors have > yet to approve our bug fix. > > so my question now is this: is recompiling the rxtx source code the only way > to solve this problem? because if it's the only > solution, then i think my superiors would rather have a new release from the > rxtx community itself that fixes this bug(?) > rather than have my team recompile the source code. > > best regards, > > chris > > Trent Jarvi wrote: > > Hi Joachim > > It would be nice to have that functionality but calling the program > introduces too many issues imho. Explaining to someone why rxtx invoked a > rogue lsof does not sound very interesting. > > On Fri, 16 Mar 2007, Joachim Buechse wrote: > > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: > > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. > > _______________________________________________ > Rxtx mailing list > Rxtx 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 Eric.Arseneau at sun.com Tue Mar 20 11:47:33 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Tue, 20 Mar 2007 10:47:33 -0700 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 Message-ID: <46001E35.9040608@sun.com> Anyone have any experience with RXTX working with JDK 6 on other platforms ? From mm at UDel.Edu Tue Mar 20 12:18:29 2007 From: mm at UDel.Edu (Mike Markowski) Date: Tue, 20 Mar 2007 14:18:29 -0400 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 In-Reply-To: <46001E35.9040608@sun.com> References: <46001E35.9040608@sun.com> Message-ID: <46002575.4000306@udel.edu> Eric Arseneau wrote: > Anyone have any experience with RXTX working with JDK 6 on other platforms ? I'm using 32 bit intel, gentoo linux, jdk6 with no problems. My applications only use a serial port, though, nothing on the parallel port. Mike From falko.guderian at gmx.de Wed Mar 21 08:17:35 2007 From: falko.guderian at gmx.de (Falko Guderian) Date: Wed, 21 Mar 2007 15:17:35 +0100 Subject: [Rxtx] RXTX binaries for SH4 Message-ID: <46013E7F.40102@gmx.de> Dear developers, I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no possiblities to compile the source code. Better, I'm not able to do this at the moment. Can you provide me with rxtxSerial.dll (SH4) in the rxtx-2.1-8-testing version? (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) The reason for the testing version is I need custom baud rates. Thanks for help. Kind regards, Falko Guderian From tjarvi at qbang.org Wed Mar 21 21:38:37 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Mar 2007 21:38:37 -0600 (MDT) Subject: [Rxtx] RXTX binaries for SH4 In-Reply-To: <46013E7F.40102@gmx.de> References: <46013E7F.40102@gmx.de> Message-ID: On Wed, 21 Mar 2007, Falko Guderian wrote: > Dear developers, > > I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no > possiblities to compile the source code. Better, I'm not able to do this > at the moment. Can you provide me with rxtxSerial.dll (SH4) in the > rxtx-2.1-8-testing version? > (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) > > The reason for the testing version is I need custom baud rates. > > Thanks for help. > Hi Falko WinCE binary format is not supported by gcc. That makes compiling limited to those familiar with the WinCE tools. I hope someone is able to provide them for you but it is not likely. WinCE has been compiled by others in the past but rxtx.org builds have never included WinCE. There is some information with the source concerning WinCE builds if you decide to do it. We can share your results too if you like. The source in the WinCE has never been updated for the custom baud rate. That would need changes from the main source I presume. If you look at the source, you will note that Michal Hobot created a mini fork in the source to handle wince but it has not been updated for 3 years. -- Trent Jarvi tjarvi at qbang.org From Adrien.TOS at ingenico.com Thu Mar 22 07:08:55 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Thu, 22 Mar 2007 14:08:55 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Hi everybody, Do you have any comments on this issue? Thanks! AT ________________________________ De : Adrien TOS Envoy? : vendredi 16 mars 2007 12:11 ? : 'rxtx at qbang.org' Cc : Adrien TOS Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070322/2306c538/attachment-0072.html From jeremy.reeve at zen.co.uk Mon Mar 19 07:36:04 2007 From: jeremy.reeve at zen.co.uk (Jeremy S. Reeve) Date: Mon, 19 Mar 2007 13:36:04 +0000 Subject: [Rxtx] rxtx failing to compile on Fedora Core 6 Message-ID: <1174311364.21865.6.camel@d9thc> When trying to compile latest source : rxtx-2.1-7r2 I get the following when running configure: ---------------- checking os.version 2.6.18-1.2200.fc5smp WARNING: configure is having a hard time determining which directory contains the file jni_md.h. Edit Makefile and fix the variable JAVANATINC to point to the correct directory. The following options are available: /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/ /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/linux/ If there are more than one option available the first was selected. WARNING: Kernel include files do not match the current kernel configure: creating ./config.status ------------------------ which seems OK checking the resultant Makefile but when attempting to build with gmake install I get the following output : ---------------------- 34 problems (34 warnings)/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/javah -classpath .:/home/jsr/rxtxsrc/rxtx-2.1-7r2:/home/jsr/rxtxsrc/rxtx-2.1-7r2/src:/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/ext/RXTXcomm.jar -d i686-pc-linux-gnu -jni `(for i in CommDriver CommPortEnumerator CommPortIdentifier CommPort CommPortOwnershipListener Configure I2C I2CPortEvent I2CPortEventListener I2CPort LPRPort NoSuchPortException ParallelPortEvent ParallelPortEventListener ParallelPort PortInUseException Raw RawPortEvent RawPortEventListener RawPort RS485 RS485PortEvent RS485PortEventListener RS485Port RXTXCommDriver RXTXPort RXTXVersion SerialPortEvent SerialPortEventListener SerialPort UnsupportedCommOperationException UnSupportedLoggerException Zystem;do \ if grep > /dev/null native.* \( /home/jsr/rxtxsrc/rxtx-2.1-7r2/./src/$i.java; then \ echo gnu.io.$i; \ fi; \ done)` i686-pc-linux-gnu/gnu_io_CommPortIdentifier.h: No such file or directory make: *** [/home/jsr/rxtxsrc/rxtx-2.1-7r2/gnu/io/CommDriver.class] Error 1 ------------------------ Any ideas or pointers? Regards, Jeremy From tjarvi at qbang.org Sat Mar 24 08:12:54 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 Mar 2007 08:12:54 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > From Adrien.TOS at ingenico.com Sat Mar 24 11:53:22 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Sat, 24 Mar 2007 18:53:22 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> I do not have the threshold setting enabled, I have explicitely disabled it with: port_.disableReceiveThreshold(); I have also run the same tests with the threshold setting enabled, but they also fail in the same way as described below. So it seems there is a problem with timeout handling on Win32? ________________________________ From: rxtx-bounces at qbang.org on behalf of Trent Jarvi Sent: Sat 3/24/2007 3:12 PM To: RXTX Developers and Users Subject: Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 8312 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20070324/f9e39c9b/attachment-0070.bin From greg.johnson at manchester.ac.uk Sun Mar 25 13:41:36 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Sun, 25 Mar 2007 21:41:36 +0200 Subject: [Rxtx] Mac intel weirdness Message-ID: Hi folks, I'm trying to get rxtx to work on my macbook pro with a USB-serial dongle on it. I am using the 2.1-8 code from the CVS (though it seems to report itself as 2.1-7: makes it difficult to prove to oneself that the changes have 'taken'! - line 4210 in SerialImp.c, line 40 in RXTXVersion.java) I am trying the 2.1-8 because of horrible lock problems in 2.1-7. However, the serialport closure code seems to be broken - it won't close because it believes the (previously opened!) port doesn't exist. Here is what I'm trying: 0. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "false" 1. Open a port Serialport serialport = (SerialPort) commportidentifier.open ("test",100); 2. Talk to a device ... 3. Close port serialport.close(); 4. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "true" - why is this? 5. Try to reopen port Serialport serialport2 = (SerialPort) commportidentifier.open("test", 100); throws PortInUseException. I've dug around a bit in the source, and it seems the SerialPort.close () should call the CommPortIdentifier.internalClosePort() (line 67 of CommPort.java). However, I crash out with the NoSuchPortException when getPortIdentifier is called. Which seems quite weird to me, seeing as it is called on this - which was create just beforehand. Does anyone know how to fix this? Cheers, greg From knute at frazmtn.com Sat Mar 24 10:32:38 2007 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 24 Mar 2007 09:32:38 -0700 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc>, Message-ID: <4604F036.17833.135298@knute.frazmtn.com> > >The behavior of timeout depends upon the setting of the threshold. Do you >have the threshold setting? > This is the same bug I reported last fall. There was a fellow that sent me an email asking if it had been fixed. I told him I didn't think so. He got somebody to write a fix for him but I have not been able to contact him again for the actual changes. The inaccurate timeout and the failure of blocking when no timeouts are set is a serious bug in my humble opinion and renders the software unusable for my applications. I'd really like to have an alternative to the Sun comm api but there just isn't one that I know of. -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Mar 26 16:17:00 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 26 Mar 2007 16:17:00 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> Message-ID: >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. From ra85551 at gmail.com Tue Mar 27 10:18:36 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Tue, 27 Mar 2007 20:18:36 +0400 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Ultimately I found a solution. At first, that wasn't actually the VMWare + WinXP + RXTX issue, that was WinXP + RXTX issue. But on pure XP it sometimes workes, sometimes not, while under VMWare I had never seen my snippet working at all. SimpleSnuV1.java would not help me, because there is only one line I missed, and SimpleSnuV1.java also doesn't contain it! It is as follows: serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_OUT | SerialPort.FLOWCONTROL_RTSCTS_IN); Thank you for your attention. -- Pavel Parkhomenko From griff at op.pl Wed Mar 28 01:28:19 2007 From: griff at op.pl (griff@op.pl) Date: Wed, 28 Mar 2007 09:28:19 +0200 Subject: [Rxtx] No blocking read on Windows. Message-ID: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/5d07d571/attachment-0067.html -------------- next part -------------- Hi, I have problem that InputStram.read() (SerialPort)?returns -1 instead blocking and waiting for data. I found that this problem was ?known in 2005 : ? >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > >> Hi Trent >> >> Thanks for the fast response. >> Here's a Q&D test program for the blocking read on windows that just >> attempts to read one byte, and prints the resulting byte. On my system it >> returns -1, where I expect that it keeps waiting for data. >> >This isn't happening on Linux so the bug is in src/termios.c.? I'll have >something this weekend to fix that. I'm using RXTX 2.1.7r2 and the problem still is here. Im using Windows XP and java 1.5 disableReciveTimeout() and disableReciveTreshhold() dont help. ? best regards ? Piotr Zielniok From Adrien.TOS at ingenico.com Wed Mar 28 01:40:46 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Wed, 28 Mar 2007 09:40:46 +0200 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903E88880@frsnprexc1.usr.ingenico.loc> Looking at the code, it seems there is no support for infinite timeout? And maybe the count++ < 20 condition is breaking out of the loop too early? The only condition to break out of the loop should either be the timeout has expired or the number of requested bytes has been received. -----Message d'origine----- De : rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] De la part de Trent Jarvi Envoy? : mardi 27 mars 2007 00:17 ? : RXTX Developers and Users Objet : Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From j.kenneth.gentle at acm.org Wed Mar 28 06:44:15 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 28 Mar 2007 08:44:15 -0400 Subject: [Rxtx] No blocking read on Windows. In-Reply-To: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> References: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> Message-ID: <200703281844.l2SIiITW028614@qbang.org> Just another "ME TOO!" - I'm seeing this problem on Windows XP, jre for windows XP/Embedded. I cranked receiveTimeout up to Integer.MAX_INT, but it doesn't seem to wait that long At 03:28 2007-03-28, you wrote: >Hi, >I have problem that InputStram.read() (SerialPort) returns -1 >instead blocking and waiting for data. I found that this problem >was known in 2005 : > > >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > > > >> Hi Trent > >> > >> Thanks for the fast response. > >> Here's a Q&D test program for the blocking read on windows that just > >> attempts to read one byte, and prints the resulting byte. On my system it > >> returns -1, where I expect that it keeps waiting for data. > >> > > >This isn't happening on Linux so the bug is in src/termios.c. I'll have > >something this weekend to fix that. > >I'm using RXTX 2.1.7r2 and the problem still is here. >Im using Windows XP and java 1.5 >disableReciveTimeout() and disableReciveTreshhold() dont help. > >best regards > >Piotr Zielniok > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From greg.johnson at manchester.ac.uk Wed Mar 28 14:43:29 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Wed, 28 Mar 2007 22:43:29 +0200 Subject: [Rxtx] Cannot close and reopen serial port Message-ID: <377F9765-7A9D-4CE9-9176-FFB63A2594F0@manchester.ac.uk> Dear all, It appears I cannot close a port properly: SerialPort serialport = portid.open("myprog",100); // do some stuff, all works fine serialport.close(); // all seems fine but... SerialPort sp2 = portid.open("myprog",100); throws PortInUseException. And when I dig into the rxtx code, I find in CommPort.java, in close(): CommPortIdentifier cp = CommPortIdentifier.getPortIdentifier(this); (line 64 or there abouts) but this throws a NoSuchPortException which is caught but ignored (line 74ish). Can anyone suggest how this could happen: a port that was valid, opened, and used, throws a NSPE when it comes to closing it? I'm pulling my (remaining) hair out over this one! Cheers, greg PS And thanks for RXTX - it's great to have! PPS (21.-7. winxp/osx both, java 1.5) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/c28852fc/attachment-0066.html From rxtx at vrijheidslaan.net Fri Mar 30 16:52:50 2007 From: rxtx at vrijheidslaan.net (Rob) Date: Fri, 30 Mar 2007 22:52:50 -0000 Subject: [Rxtx] Cvs Question Message-ID: <61896.80.126.150.87.1175295162.squirrel@webmail.provalue.nl> Hi There, Im trying to get the latest version to work on mac osx. Problem is that i can't checkout version 2.1.8. Probably my fault but can some one please give me the alternative commands for: [user at myhost]$ export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot [user at myhost]$ cvs login Thanx, Rob From ra85551 at gmail.com Thu Mar 1 03:47:06 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Thu, 1 Mar 2007 13:47:06 +0300 Subject: [Rxtx] enableReceiveTimeout() issue Message-ID: Hello, world! I found a limitation of 16300 ms for CommPort's enableReceiveTimeout() method, while in original javax.comm docs there are no any references to that. Is that a bug or feature? I actually need longer timeouts sometimees. -- Pavel Parkhomenko From lyon at docjava.com Thu Mar 1 07:54:17 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 01 Mar 2007 09:54:17 -0500 Subject: [Rxtx] parametric singleton design pattern In-Reply-To: References: <22d55aea0702081207q5e7f6785l352d498d6f5f9fb1@mail.gmail.com> <22d55aea0702100034o3bcf42f3j1d1a6257029a67b0@mail.gmail.com> Message-ID: Hi All, I have been thinking about the use of a design pattern to cache resources that are consumed by processes. Toward that end, I have arrived at a parametric singleton design pattern, which I mentioned on this list some time ago. The idea has been published at: http://www.jot.fm/issues/issue_2007_03/column2 I can't help but think that there should be an API available for dealing with the tracking of serial port usage. Perhaps it is a kind of resource manager called the: SerialPortManager basic prototypes already exist in this vain. See, for example: http://www.ce.rit.edu/research/projects/2005_fall/rt_poolsystem/doc/PoolMon/SerialPortManager.html http://www.eventhelix.com/RealtimeMantra/PatternCatalog/serial_port_design_pattern.htm And others shown by a google search on "SerialPortManager" Cheers! - Doug From Eric.Arseneau at sun.com Thu Mar 1 10:15:03 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:15:03 -0800 Subject: [Rxtx] Any known Java 6 issues with RXTX 2.1-7r2 ? Message-ID: <45E70A17.1060206@sun.com> I just did a test on a recent build of Solaris 11 x86 and it seems that I can connect to my serial device fine when Java 5 is the default, but when Java 6 is the default, no go. Any information ? From Eric.Arseneau at sun.com Thu Mar 1 10:19:58 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:19:58 -0800 Subject: [Rxtx] Mac OS X and missing data Message-ID: <45E70B3E.7040908@sun.com> We have a device which is USB based but presents itself as a serial port to a machine. On my MacBook Pro I can get excellent throughput if I get my device to send data as quickly as possible. On the desktop side, if I do an type of disk IO to log the data I get, I end up with some missing data at some point. I hooked up a USB analyzer and did confirm that all the data is sent as expected to the desktop from the device. I found a work around for this, buffer the data in memory and only write the data out when I've received it all. However, when the same code and same device is attempted on a co-workers MacBook Pro (same hardware specs), I get errors and must slow down dramatically the device side's sending of data. Any ideas/recommendations on what I can do to get rid of this error ? From what I can tell, it seems that RXTX is not able to wake up to the interrupts coming in indicating data is ready, quickly enough, is there anything I can do ? From chinkaiw at hotmail.com Fri Mar 2 00:57:43 2007 From: chinkaiw at hotmail.com (Wang Chinkai) Date: Fri, 02 Mar 2007 07:57:43 +0000 Subject: [Rxtx] dynamic detect rs232 port Message-ID: Hi all I have a question about detecting rs232 port dynamicly. I have to aceess some port and detect rs232 port at the same time. Some usb device simulates rs232 port , and I can not know what the port name it gets until it connects,so I have to detect it dynamic,but I have to access another rs232 device at the same time. I found a problem. If I use CommPortIdentifier.getPortIdentifiers() to get new port list , and the other rs232 access function will not close port correctly. So , How can I solve it . Thanks. _________________________________________________________________ ?? 2GB ???? Windows Live Mail ????????????? http://ideas.live.com/programpage.aspx?versionid=5d21c51a-b161-4314-9b0e-4911fb2b2e6d From eu259473 at tele2.it Fri Mar 2 06:16:40 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 02 Mar 2007 14:16:40 +0100 Subject: [Rxtx] rxtx on HP tru 64 unix Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070302/706c7a70/attachment-0094.html From tjarvi at qbang.org Fri Mar 2 08:39:33 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 08:39:33 -0700 (MST) Subject: [Rxtx] rxtx on HP tru 64 unix In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, "Giuseppe Marchese" wrote: > Hi > > I try to install rxtx on hp tru 64 but make fails, > There are somebody that do the same and work. > > > Sorry for may english! > > Hi Giuseppe Could you provide a log of the failure? script ./configure make # use gnu make exit The information will be in the typescript created. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 2 19:56:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 19:56:52 -0700 (MST) Subject: [Rxtx] dynamic detect rs232 port In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, Wang Chinkai wrote: > Hi all > > I have a question about detecting rs232 port dynamicly. > > I have to aceess some port and detect rs232 port at the same time. > Some usb device simulates rs232 port , and I can not know > what the port name it gets until it connects,so I have to detect it > dynamic,but I have to access > another rs232 device at the same time. > > I found a problem. Hi Wang This is a known problem. The code is braindead there. In fact there needs to be events even in a rudamentary way when you add a usb dongle. I'm burried in tasks not far from rxtx but not in rxtx. I can't get to the problem but we would accept patches if you dig into it. [I'm getting to the license question earlier too; I don't have another 10%] -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Fri Mar 2 23:19:01 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 01:19:01 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Hi, Under ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable USB -> serial converter(using virtual com port drivers), with using example code pretty much straight out of http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port opens fine, enumerations all work, etc. My application calls for a large amount of data to be transferred in a short amount of time at 2,000,000 baud. My hardware sends approximately 15,232 bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL converter work fine, and the application works using C++. In C++, I do a hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); to open the port, and a boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); to read the port. The variable buffer fills with the 15238 bytes, and returns. If I do a resultz = is.read(cbuf,0,15238); in java with RXTX where is = new BufferedReader(new InputStreamReader(port.getInputStream())); and where resultz is an int, and cbuf is a char [] cbuf, resultz gets EXACTLY 3968 bytes the first time called. If I call it multiple times, I get roughly 11k total(less than what is sent), never more than the 3968 bytes per is.read() call. My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 bytes. I've played with inputbuffersize, receive threshold, receivetimeout, and so on. The FTDI virtual com port drivers that I'm using are rock solid, and have had zero problems with them using a variety of applications, some of my own, some professionally written, etc. No flow control is used anyplace, no RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. No exceptions are being thrown. What am I doing wrong, and what I can adjust to receive the full 15k bytes in one single read? Thanks! Keith From Eric.Arseneau at sun.com Fri Mar 2 23:32:07 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Fri, 02 Mar 2007 22:32:07 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <45E91667.20501@sun.com> This is the same type of thing that is happening to me on Mac OS X and does not seem to behave the same on different machines. I posted a day or two ago on this with subject "Mac OS X and missing data". Would love to hear if there is a solution to this :) From tjarvi at qbang.org Sat Mar 3 10:54:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 10:54:17 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > Hi, > > Under > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable > USB -> serial converter(using virtual com port drivers), with using example > code pretty much straight out of > http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port > opens fine, enumerations all work, etc. > > My application calls for a large amount of data to be transferred in a short > amount of time at 2,000,000 baud. My hardware sends approximately 15,232 > bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL > converter work fine, and the application works using C++. > > In C++, I do a > > hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, > OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); > > to open the port, and a > > boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); > > to read the port. > > The variable buffer fills with the 15238 bytes, and returns. > > If I do a > > resultz = is.read(cbuf,0,15238); in java with RXTX > > where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > > and where resultz is an int, and cbuf is a char [] cbuf, resultz gets > EXACTLY 3968 bytes the first time called. If I call it multiple times, I get > roughly 11k total(less than what is sent), never more than the 3968 bytes > per is.read() call. > > My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 > bytes. > > I've played with inputbuffersize, receive threshold, receivetimeout, and so > on. The FTDI virtual com port drivers that I'm using are rock solid, and > have had zero problems with them using a variety of applications, some of my > own, some professionally written, etc. No flow control is used anyplace, no > RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. > > No exceptions are being thrown. > > What am I doing wrong, and what I can adjust to receive the full 15k bytes > in one single read? > > Thanks! > Hi Keith I would expect a 20 meg application is going to have different behavior with the OS than a smaller application with respect to the kernel memory managment, schedualing, ... Something subtle could be causing problems. With respect to the recieve timeout and threshold, if you set the timeout to zero and the threshold to the size of data you expect, read should not return until it get that data. You may try with a stand alone application that tests just that with the C/C++ API. If the read is returning with less data when tested for short reads, you have found a bug in the device driver more than likely. The USB dongle vendor would probably be interested in knowing about this. As mentioned, these devices are getting very good; almost bug free. I suspect you found a bug though if you did use the threshold and timeout properly. The missing data is typical when not using flow control. When the OS buffering fills, the hardware will start dropping bytes. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:38:52 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:38:52 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> update: I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now instead of 3968. This makes sense. 128 bytes of overhead + 3968 bytes of data = 4096 transfer size 32 bytes of overhead + 992 bytes of data = 1024 transfer size. 1/4 the data = 1/4 the overhead. I rearranged my reading like so: resultz = is.read(cbuf,0,3968); resultz = is.read(cbuf,3968,3968); resultz = is.read(cbuf,7936,3968); while (!(is.ready())); // wait for ready resultz = is.read(cbuf,11904,3334); and this grabs 15,238 bytes total. BUT, I still have the quandry of the screwed up multi-bytes. I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. Approx 8% of the data. The bad bytes always seem to take the flavor of 0x2018, 0x2019, x2022, x2030, x201d. Are these maybe errors and I don't know what they enumerate to? I still can't believe some other layer isn't handling putting those bytes together all in one stream for me. Thanks Keith ----- Original Message ----- From: "Keith" To: "Bob Jacobsen" ; "RXTX Developers and Users" Sent: Saturday, March 03, 2007 11:26 AM Subject: Re: [Rxtx] is.read() only returning 3968 bytes > Bob, > > > Interesting numerical coincidence is that (max USB transfer) - (what > > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > > needed to transfer that much data. > > I was thinking along the same lines. I don't know USB well, but I do know > that those numbers were close enough to warrant investigating the > relationship between them. > > > I think what you're seeing is the internal buffering of the USB data > > stream. You'll need some form of higher-level buffering to smooth > > that out. > > Shouldn't the InputStreamReader() and BufferedReader() provide this type of > buffering? Isn't that the idea behind those? > > > All hypotheses need to be tested. In this case, a test would be to > > check for missing data. If this idea is right, you'll get _all_ the > > data, but you won't be missing characters. > > I did start looking at the data. -- I'm getting weird results. > > I tried this: > > loopzz = 0; > > for (looptwo = 0; looptwo < 100000; looptwo++) { > while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > > }} > > So I'm reading one character at a time. The good news is that loopzz is > exactly 15238 at the end of the routine, which is perfectly correct. I > picked looptwo value out of thin air. > > The weird results come in terms of the values, the data isn't correct at > least in one case. Look here: > > 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > > This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). > But the 0x89 was replaced by 0x2030. Why the heck would the returned value > be 0x2030?? Why is the returned byte completely out of range? Why the > multibyte return? > > From InputStream in the API: > > read > public abstract int read() > throws IOExceptionReads the next byte of data from the > input stream. The value byte is returned as an int in the range 0 to 255. If > no byte is available because the end of the stream has been reached, the > value -1 is returned. This method blocks until input data is available, the > end of the stream is detected, or an exception is thrown. > Value should be 0-255. > > > In my application time is really critical, reading 1 byte at a time is > probably not going to work. > > Thanks Eric & Bob for looking at this. > > Keith > From tjarvi at qbang.org Sat Mar 3 12:52:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 12:52:27 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > update: > > I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now > instead of 3968. > > This makes sense. > > 128 bytes of overhead + 3968 bytes of data = 4096 transfer size > 32 bytes of overhead + 992 bytes of data = 1024 transfer size. > > 1/4 the data = 1/4 the overhead. > > I rearranged my reading like so: > > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. > Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? > > I still can't believe some other layer isn't handling putting those bytes > together all in one stream for me. > The layer for this in Serial land is flow control. Software and hardware flow control prevent the overruns you observe. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:54:41 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:54:41 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <001a01c75dcd$c8802a70$6600a8c0@jbh757ktruws7g> Trent, Thanks for taking the time to reply. > I would expect a 20 meg application is going to have different behavior > with the OS than a smaller application with respect to the kernel memory > managment, schedualing, ... Something subtle could be causing problems. Well, at least I know the VCP drivers, the OS, etc can handle 2mbps reliably. Without hiccuping or dropping bytes. The C++ code works reliably without flow control. > The missing data is typical when not using flow control. When the OS > buffering fills, the hardware will start dropping bytes. I'm actually not getting MISSING data, I'm getting CORRUPTED data. If you look at my most recent post, I'm getting these bad bytes in place of the correct values: 0x2018, 0x2019, x2022, x2030, x201d. Why would is.read() return values not in the range of 0-255 ? Thanks. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 08:59:14 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 07:59:14 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: At 1:19 AM -0500 3/3/07, Keith wrote: >If I do a > >resultz = is.read(cbuf,0,15238); in java with RXTX > >where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > >and where resultz is an int, and cbuf is a char [] cbuf, resultz gets >EXACTLY 3968 bytes the first time called. If I call it multiple times, I get >roughly 11k total(less than what is sent), never more than the 3968 bytes >per is.read() call. > >My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 >bytes. Interesting numerical coincidence is that (max USB transfer) - (what you get) = 4096-3968 = 128 bytes is (almost) the size of the headers needed to transfer that much data. I think what you're seeing is the internal buffering of the USB data stream. You'll need some form of higher-level buffering to smooth that out. All hypotheses need to be tested. In this case, a test would be to check for missing data. If this idea is right, you'll get _all_ the data, but you won't be missing characters. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 09:26:14 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 11:26:14 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Bob, > Interesting numerical coincidence is that (max USB transfer) - (what > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > needed to transfer that much data. I was thinking along the same lines. I don't know USB well, but I do know that those numbers were close enough to warrant investigating the relationship between them. > I think what you're seeing is the internal buffering of the USB data > stream. You'll need some form of higher-level buffering to smooth > that out. Shouldn't the InputStreamReader() and BufferedReader() provide this type of buffering? Isn't that the idea behind those? > All hypotheses need to be tested. In this case, a test would be to > check for missing data. If this idea is right, you'll get _all_ the > data, but you won't be missing characters. I did start looking at the data. -- I'm getting weird results. I tried this: loopzz = 0; for (looptwo = 0; looptwo < 100000; looptwo++) { while (is.ready()) { cbuf[loopzz] = (char) is.read(); loopzz++; }} So I'm reading one character at a time. The good news is that loopzz is exactly 15238 at the end of the routine, which is perfectly correct. I picked looptwo value out of thin air. The weird results come in terms of the values, the data isn't correct at least in one case. Look here: 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). But the 0x89 was replaced by 0x2030. Why the heck would the returned value be 0x2030?? Why is the returned byte completely out of range? Why the multibyte return? >From InputStream in the API: read public abstract int read() throws IOExceptionReads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown. Value should be 0-255. In my application time is really critical, reading 1 byte at a time is probably not going to work. Thanks Eric & Bob for looking at this. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 14:44:50 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 13:44:50 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: Java's "char" type is Unicode. I think what you're seeing is a bug in the byte -> Unicode translation. 0x2018, 0x2019 are the curly open and close quotes. There used to be (and might still be) bugs in the conversion of these in a couple of libc versions. Some of the ASCII -> ISO and ISO -> ASCII routines were a little over-ambitious with respect to handling the open and close quotes, and tried to convert them to the "curly" form inappropriately. Try _not_ casting it to char. Bob At 11:26 AM -0500 3/3/07, Keith wrote: >Bob, > >> Interesting numerical coincidence is that (max USB transfer) - (what >> you get) = 4096-3968 = 128 bytes is (almost) the size of the headers >> needed to transfer that much data. > >I was thinking along the same lines. I don't know USB well, but I do know >that those numbers were close enough to warrant investigating the >relationship between them. > >> I think what you're seeing is the internal buffering of the USB data >> stream. You'll need some form of higher-level buffering to smooth >> that out. > >Shouldn't the InputStreamReader() and BufferedReader() provide this type of >buffering? Isn't that the idea behind those? > >> All hypotheses need to be tested. In this case, a test would be to >> check for missing data. If this idea is right, you'll get _all_ the >> data, but you won't be missing characters. > >I did start looking at the data. -- I'm getting weird results. > >I tried this: > >loopzz = 0; > >for (looptwo = 0; looptwo < 100000; looptwo++) { >while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > >}} > >So I'm reading one character at a time. The good news is that loopzz is >exactly 15238 at the end of the routine, which is perfectly correct. I >picked looptwo value out of thin air. > >The weird results come in terms of the values, the data isn't correct at >least in one case. Look here: > >0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > >This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). >But the 0x89 was replaced by 0x2030. Why the heck would the returned value >be 0x2030?? Why is the returned byte completely out of range? Why the >multibyte return? > >>From InputStream in the API: > >read >public abstract int read() > throws IOExceptionReads the next byte of data from the >input stream. The value byte is returned as an int in the range 0 to 255. If >no byte is available because the end of the stream has been reached, the >value -1 is returned. This method blocks until input data is available, the >end of the stream is detected, or an exception is thrown. >Value should be 0-255. > > >In my application time is really critical, reading 1 byte at a time is >probably not going to work. > >Thanks Eric & Bob for looking at this. > >Keith > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 15:10:11 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 17:10:11 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Bob said ..... > Java's "char" type is Unicode. I think what you're seeing is a bug > in the byte -> Unicode translation. Bob -- I think you hit the nail on the head. I was just coming to the same realization here. I knew that something funny was going on because the same bytes always got "corrupted." I'm pretty sure its in the InputStreamReader() functionality where the conversion junk is happening. Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. I don't know if simply changing the cast is going to work. Since the conversion is happening upstream (pun intended), I don't think my cast is doing this. Also I think the compiler forced me to use the cast. I'm still playing around, and I'll report back once I nail it down. Thanks!! Keith From tjarvi at qbang.org Sat Mar 3 15:59:46 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 15:59:46 -0700 (MST) Subject: [Rxtx] Win64 rxtx Testers? Message-ID: I have compiled win64 binaries of rxtx. Are there any users interested in testing them? If so, I'll look into putting them on the web site. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Mar 3 15:35:06 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 14:35:06 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: Because of this and similar problems, JMRI does all it's serial IO using +only+ byte values. It's a but of a pain, as Java wants to go to char and int types a little too aggressively, but it does solve the "uncontrolled conversions" problems. Bob At 5:10 PM -0500 3/3/07, Keith wrote: >Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > >Bob -- I think you hit the nail on the head. > >I was just coming to the same realization here. I knew that something funny >was going on because the same bytes always got "corrupted." > >I'm pretty sure its in the InputStreamReader() functionality where the >conversion junk is happening. > >Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > >I don't know if simply changing the cast is going to work. Since the >conversion is happening upstream (pun intended), I don't think my cast is >doing this. Also I think the compiler forced me to use the cast. -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mark at mdsh.com Sun Mar 4 11:01:33 2007 From: mark at mdsh.com (Mark Himsley) Date: Sun, 04 Mar 2007 18:01:33 +0000 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: <5C01AC72C200388815C04982@bedroom.mdsh.local> On 03 March 2007 14:38 -0500 Keith wrote: > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT > consistent. Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? It looks like you need to use DataInputStream and DataOutputStream. -- Mark Himsley From tjarvi at qbang.org Sun Mar 4 11:35:08 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 11:35:08 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" > > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > > * Line #21 - Not sure if you need a (TM) mark for > the term "Sun" > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > OK. I'm going through this today. Some groups ask if rxtx could be under their license also. I think this is a good example of why I resist multiple licenses and focus on why the current license may not be usable by them. The RXTX project is a convergence of hobby and commercial interests. I happen to do both right now. The problem with licensing is we have to stay on top of them as they change. Clearly, adding more licenses will not make this easier. I'm acting as the hobby person today. RXTX always favors the hobby people. But as we move forward, I'm going to need to bring this to lawyers at work and explain to them what is going on. Others here may have to do this also. I don't anticipate problems or unexpected changes. The goal is a consistant, comprehendable and usable license as close to what we have now as possible. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 14:52:10 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 14:52:10 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (1/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: I'm breaking this into two parts. I expect the second part will need more attention. Comments first, then the changed material below. On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > Thanks > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. OK. RXTX for consitent use. java should not be capitalized because it does not only mean Sun [TM] Java [TM]. An example of this not meaning Java is when people use RXTX with GCJ. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". There are not any contributors that are in all of RXTX yet but I did update the comment to try to reflect the current situation without making it a nightmare to maintain. I looked to see how the Linux kernel does it as a reference point. > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" The URL can be problematic. I have done so below with a time reference. GNU does not provide version information in their URLS. I picture this being a problem when the version 3 comes out. > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > This will be corrected when the copy is updated to the version linked below. ---------------- begin proposed material involved -------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. ----------------- end proposed material involved -------------------- I'll be looking at the linking issue again next. That should be all that remains other than including the 2.1 version. Let me know if you have problems with anything here. I do not want to dilute the material I post next with these housekeeping tasks. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 16:08:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 16:08:36 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: For those that are wondering what is going on here, this next bit is the meat of the changes. We agreed a long time ago to put this disclaimer in. We did a so so job. It was in rxtx 2.0, not well written, ... So some groups using rxtx that would like to ship rxtx so users don't need to download, install, go to the mail-list to find why it failed, ... Then their legal teams tell them section 5 paragraph 2 is a show stopper. That was never the intent. Now going through what remains... > and might need a (TM) suffix to make Sun happy. Added disclaimer at the ended 'all trademarks belong...' > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. OK. As you can see I was trying to adjust GNU text there for the LGPL. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. used dynamically linked terminology. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". I tried to address this more upfront with an intent statement. Let me know if you have problems with it. I also tried to make it a little more clear what was derived from the GNU solution by moving the link location closer to GNU's suggestion. > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > Thats the intent. Here is the combined fixes. Note that only the material in /*-- --*/ is being touched. The new GPL license is there but unmodified. ------------------------ begin proposed new license ------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. | | An executable that contains no derivative of any portion of RXTX, but | is designed to work with RXTX by being dynamically linked with it, | is considered a "work that uses the Library" subject to the terms and | conditions of the GNU Lesser General Public License. | | The following has been added to the RXTX License to remove | any confusion about linking to RXTX. We want to allow in part what | section 5, paragraph 2 of the LGPL does not permit in the special | case of linking over a controlled interface. The intent is to add a | Java Specification Request or standards body defined interface in the | future as another exception but one is not currently available. | | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface | | As a special exception, the copyright holders of RXTX give you | permission to link RXTX with independent modules that communicate with | RXTX solely through the Sun Microsytems CommAPI interface version 2, | regardless of the license terms of these independent modules, and to copy | and distribute the resulting combined work under terms of your choice, | provided that every copy of the combined work is accompanied by a complete | copy of the source code of RXTX (the version of RXTX used to produce the | combined work), being distributed under the terms of the GNU Lesser General | Public License plus this exception. An independent module is a | module which is not derived from or based on RXTX. | | Note that people who make modified versions of RXTX are not obligated | to grant this special exception for their modified versions; it is | their choice whether to do so. The GNU Lesser General Public License | gives permission to release a modified version without this exception; this | exception also makes it possible to release a modified version which | carries forward this exception. | | You should have received a copy of the GNU Lesser General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA | All trademarks belong to their respective owners. --------------------------------------------------------------------------*/ The original GNU Lesser General Public License Follows. GNU LESSER GENERAL PUBLIC LICENSE Version 2.1, February 1999 Copyright (C) 1991, 1999 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. [This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence the version number 2.1.] Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This license, the Lesser General Public License, applies to some specially designated software packages--typically libraries--of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below. When we speak of free software, we are referring to freedom of use, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish); that you receive source code or can get it if you want it; that you can change the software and use pieces of it in new free programs; and that you are informed that you can do these things. To protect your rights, we need to make restrictions that forbid distributors to deny you these rights or to ask you to surrender these rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library or if you modify it. For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights. We protect your rights with a two-step method: (1) we copyright the library, and (2) we offer you this license, which gives you legal permission to copy, distribute and/or modify the library. To protect each distributor, we want to make it very clear that there is no warranty for the free library. Also, if the library is modified by someone else and passed on, the recipients should know that what they have is not the original version, so that the original author's reputation will not be affected by problems that might be introduced by others. Finally, software patents pose a constant threat to the existence of any free program. We wish to make sure that a company cannot effectively restrict the users of a free program by obtaining a restrictive license from a patent holder. Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license. Most GNU software, including some libraries, is covered by the ordinary GNU General Public License. This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs. When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library. We call this license the "Lesser" General Public License because it does Less to protect the user's freedom than the ordinary General Public License. It also provides other free software developers Less of an advantage over competing non-free programs. These disadvantages are the reason we use the ordinary General Public License for many libraries. However, the Lesser license provides advantages in certain special circumstances. For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License. In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software. For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU operating system, as well as its variant, the GNU/Linux operating system. Although the Lesser General Public License is Less protective of the users' freedom, it does ensure that the user of a program that is linked with the Library has the freedom and the wherewithal to run that program using a modified version of the Library. The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, whereas the latter must be combined with the library in order to run. GNU LESSER GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License Agreement applies to any software library or other program which contains a notice placed by the copyright holder or other authorized party saying it may be distributed under the terms of this Lesser General Public License (also called "this License"). Each licensee is addressed as "you". A "library" means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables. The "Library", below, refers to any such software library or work which has been distributed under these terms. A "work based on the Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term "modification".) "Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library. Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does. 1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) The modified work must itself be a software library. b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change. c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License. d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful. (For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library. In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. 4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange. If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code. 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables. When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law. If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.) Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself. 6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications. You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things: a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.) b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. c) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution. d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place. e) Verify that the user has already received a copy of these materials or that you have already sent this user a copy. For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute. 7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things: a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above. b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work. 8. You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 9. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Library (or any work based on the Library), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Library or works based on it. 10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties with this License. 11. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply, and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 12. If the distribution and/or use of the Library is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Library under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 13. The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation. 14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Libraries If you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the ordinary General Public License). To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Also add information on how to contact you by electronic and paper mail. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the library, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the library `Frob' (a library for tweaking knobs) written by James Random Hacker. , 1 April 1990 Ty Coon, President of Vice That's all there is to it! ------------------------ end of proposed license ------------------ -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sun Mar 4 16:26:04 2007 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 04 Mar 2007 17:26:04 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <45EB558C.3010609@cox.net> Bob Jacobsen wrote: > Because of this and similar problems, JMRI does all it's serial IO > using +only+ byte values. It's a but of a pain, as Java wants to go > to char and int types a little too aggressively, but it does solve > the "uncontrolled conversions" problems. Anytime that you are reading bytes of data that is not printable, unicode text, in Java, you really need to stay away from the Readers. Use input stream only, or you will see unicode valued byte groups converted to unicode "char" values. Gregg Wonderly From joachim at buechse.de Mon Mar 5 04:23:48 2007 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 5 Mar 2007 12:23:48 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> The behaviour is exactly what you asked for in you code. is = new BufferedReader(new InputStreamReader(port.getInputStream())); Readers return Text (ie unicode chars) not bytes. You instantiate the InputStreamReader without saying which charset you want, which means "platform default". As this is on Windows, it will convert Windows characters to equivalent unicode characters. If you want to read bytes, read bytes not Text. Reading bytes is done with InputStream and BufferedInputStream. BTW: The InputStream and Reader methods that read arrays are not guarenteed to fill up the array. You always have to check what you really got, and advance your index accordingly. A typical "read up to 32k" method looks like this: InputStream is= ... // -- determine the max buffer size int len= is.available(); if (len == 0) { len= 32 * 1024; } // -- read all available data byte[] buffer= new byte[len]; int pos= 0; int read; do { read= is.read(buffer, pos, buffer.length - pos); pos= pos + read; } while (read != -1 && pos < buffer.length); Best regards, Joachim --- Joachim B?chse Phone: +41 44 500 2604 Buechse Consulting Hadlaubsteig 2 CH-8006 Z?rich On 03.03.2007, at 23:10, Keith wrote: > Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > > Bob -- I think you hit the nail on the head. > > I was just coming to the same realization here. I knew that > something funny > was going on because the same bytes always got "corrupted." > > I'm pretty sure its in the InputStreamReader() functionality where the > conversion junk is happening. > > Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > > I don't know if simply changing the cast is going to work. Since the > conversion is happening upstream (pun intended), I don't think my > cast is > doing this. Also I think the compiler forced me to use the cast. > > I'm still playing around, and I'll report back once I nail it down. > > Thanks!! > > Keith > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Mon Mar 5 07:25:46 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 05 Mar 2007 08:25:46 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> Message-ID: <45EC286A.8060608@cox.net> Joachim Buechse wrote: > BTW: The InputStream and Reader methods that read arrays are not > guarenteed to fill up the array. You always have to check what you > really got, and advance your index accordingly. A typical "read up to > 32k" method looks like this: > > InputStream is= ... > // -- determine the max buffer size > int len= is.available(); > if (len == 0) { > len= 32 * 1024; > } > // -- read all available data > byte[] buffer= new byte[len]; > int pos= 0; > int read; > do { > read= is.read(buffer, pos, buffer.length - pos); > pos= pos + read; > } while (read != -1 && pos < buffer.length); > My preferred structure is. byte arr[ len ]; int cnt; int off = 0; while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { off += cnt; } This keeps you from adding -1 to pos when the read returns -1. It also skips out when the read is 0 bytes which, is not a described EOF in InputStream java docs, but is a condition I want to be aware of. Gregg Wonderly From joachim at buechse.de Tue Mar 6 02:52:58 2007 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 6 Mar 2007 10:52:58 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <45EC286A.8060608@cox.net> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: The code I copied was from a file resource reader, it shouldn't really be applied to networking/external IO code. Mea culpa. However aborting when you get 0 from read is not always what you want either (you kind of indicated that already). Some unix java implementations will return 0 if the kernel read was aborted with EINTER, which is rarely the point where you want to abort your read - at least not without further checks. A "complete" solution always depends on the events you need to handle and the time the total read could take in reality. In some cases it's worth checking Thread.isInterrupted() in the loop, some code re-loops on 0 but only a limited number of times, some check a total timeout limit, etc... Best regards, Joachim On 05.03.2007, at 15:25, Gregg Wonderly wrote: > My preferred structure is. > > byte arr[ len ]; > int cnt; > int off = 0; > while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { > off += cnt; > } > > This keeps you from adding -1 to pos when the read returns -1. It > also skips > out when the read is 0 bytes which, is not a described EOF in > InputStream java > docs, but is a condition I want to be aware of. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Mar 6 14:47:44 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 Mar 2007 14:47:44 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: Just FYI, rxtx will usually not break out on EINTER. The code in the native library usually does something close to this: do { read(...) } while ( !done && errno==EINTR ); Obviously there is a little more involved but it will retry on EINTER if not done. On Tue, 6 Mar 2007, Joachim Buechse wrote: > The code I copied was from a file resource reader, it shouldn't > really be applied to networking/external IO code. Mea culpa. > > However aborting when you get 0 from read is not always what you want > either (you kind of indicated that already). Some unix java > implementations will return 0 if the kernel read was aborted with > EINTER, which is rarely the point where you want to abort your read - > at least not without further checks. A "complete" solution always > depends on the events you need to handle and the time the total read > could take in reality. In some cases it's worth checking > Thread.isInterrupted() in the loop, some code re-loops on 0 but only > a limited number of times, some check a total timeout limit, etc... > > Best regards, > Joachim > > On 05.03.2007, at 15:25, Gregg Wonderly wrote: >> My preferred structure is. >> >> byte arr[ len ]; >> int cnt; >> int off = 0; >> while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { >> off += cnt; >> } >> >> This keeps you from adding -1 to pos when the read returns -1. It >> also skips >> out when the read is 0 bytes which, is not a described EOF in >> InputStream java >> docs, but is a condition I want to be aware of. >> >> Gregg Wonderly >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 gjhanna at gmail.com Thu Mar 8 13:42:52 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Fri, 9 Mar 2007 09:42:52 +1300 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? Message-ID: I've just struck an issue using rxtx in a multi-threaded environment: If I have 3 threads trying to open *the same* comm-port I get a deadlock in CommPortIdentifier.open If I have just 2, it works fine - I get a PortInUseException which is nice and I can handle it. The 3 thread->deadlock thing is causing me issues. (Sample code below). This is from the java thread-dump Found one Java-level deadlock: ============================= "Thread-2": waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object ), which is held by "Thread-1" "Thread-1": waiting to lock monitor 0x0003e9cc (object 0x2450e108, a gnu.io.CommPortIdentifier), which is held by "Thread-2" Java stack information for the threads listed above: =================================================== "Thread-2": at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:329) - waiting to lock <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) "Thread-1": at java.lang.Object.wait(Native Method) - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) - locked <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) (Apart from this, rxtx is working fantastically for us). I'm thinking I'll have to implement some sort of locking mechanism that *doesn't* use java synchronization to prevent this situation. (Which doesn't sound like a good idea to me). Any ideas? Thanks, Greg Hanna ============= RXTXLockTest.java ======================================== import gnu.io.CommPort; import gnu.io.CommPortIdentifier; /** * @author Greg Hanna * Minimal code to create a deadlock with rxtx in multithreaded open */ public class RXTXLockTest { public static void main(String[] args) { try { CommPortIdentifier cpiCom1 = CommPortIdentifier.getPortIdentifier ("COM14"); OpenThread t1 = new OpenThread (" one ", cpiCom1); OpenThread t2 = new OpenThread (" two ", cpiCom1); OpenThread t3 = new OpenThread (" 003 ", cpiCom1); t1.start(); t2.start(); t3.start(); // comment this out and it runs with (expected) PortInUseException } catch (Exception e) { e.printStackTrace(); } } } class OpenThread extends Thread { String name; CommPortIdentifier cpi; CommPort cp; public OpenThread (String name, CommPortIdentifier cpi) { this.name = name; this.cpi = cpi; System.out.println (System.currentTimeMillis() + name + " thread created"); } public void run () { try { System.out.println (System.currentTimeMillis() + name + " opening"); cp = cpi.open(name, 2000); System.out.println (System.currentTimeMillis() + name + " opened - sleeping"); sleep (2000); // do the serial comms with the device. System.out.println (System.currentTimeMillis() + name + " slept - closing"); cp.close(); System.out.println (System.currentTimeMillis() + name + " closed - exiting"); } catch (Exception e) { System.out.println ("Error in thread: " + name ); e.printStackTrace(); } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070308/d9a163c5/attachment-0087.html From eu259473 at tele2.it Fri Mar 9 02:46:20 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 09 Mar 2007 10:46:20 +0100 Subject: [Rxtx] rxtx: tru64 unix make fails Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070309/3b654523/attachment-0087.html From lyon at docjava.com Fri Mar 9 03:58:32 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 Mar 2007 05:58:32 -0500 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi All, The deadlock issue is one that I have been thinking about for some time now. It seems to me that we need a resource manager that enables assignment to a known process. The one thing that seems important about serial ports is that two applications should not use the same serial port at the same time. When this happens, it throws an exception. OK. The exception is a response to a lock condition that arises from an unavailable resource. An abstract implementation (not born of native methods) might assign a serial port to an application, until the application releases it (or is forced to release it by some kill mechanism). Some resources (like a registry) can be reused. But others, like the serial port, cannot. In the case of the serial port, we would like, I think, to have the flyweight design pattern without sharing and with object assignment tracking. A means of breaking deadlock (like a leasing mechanism) seems very useful, to me. My guess is that we can serialize the state of the Parametric Singleton Pattern (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) into the Preferences of the System. Preferences.systemRoot() might help with that. When a resource is checked out, the lease time and owner are listed. A thread that does this can be killed, but applications outside of Java are problematic. There is a compelling problem here. It is not just serial ports. Sound cards, cameras, microphones, files, tape drives, etc. All are consumed resources that are assigned to an application (or user) and deprive other applications, or users, from use. What, if anything, should we do? At present we throw PortInUseExceptions. Is that it? Can we do better? OK, the port is in use. Now what? Do I have to be root to go remove lock files and kill applications? Is there a better way? Thanks! - Doug >I've just struck an issue using rxtx in a multi-threaded environment: > >If I have 3 threads trying to open *the same* >comm-port I get a deadlock in >CommPortIdentifier.open >If I have just 2, it works fine - I get a >PortInUseException which is nice and I can >handle it. > >The 3 thread->deadlock thing is causing me issues. >(Sample code below). > >This is from the java thread-dump > >Found one Java-level deadlock: >============================= >"Thread-2": > waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), > which is held by "Thread-1" >"Thread-1": > waiting to lock monitor 0x0003e9cc (object >0x2450e108, a gnu.io.CommPortIdentifier ), > which is held by "Thread-2" > >Java stack information for the threads listed above: >=================================================== >"Thread-2": > at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) > - waiting to lock <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) >"Thread-1": > at java.lang.Object.wait(Native Method) > - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) > - locked <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) > > >(Apart from this, rxtx is working fantastically for us). > >I'm thinking I'll have to implement some sort of >locking mechanism that *doesn't* use java >synchronization to prevent this situation. >(Which doesn't sound like a good idea to me). > >Any ideas? > >Thanks, > >Greg Hanna > >============= RXTXLockTest.java ======================================== > >import gnu.io.CommPort; >import gnu.io.CommPortIdentifier; > >/** > * @author Greg Hanna > * Minimal code to create a deadlock with rxtx in multithreaded open > */ >public class RXTXLockTest { > ? > ?public static void main(String[] args) { > ?try { > ?CommPortIdentifier cpiCom1 = >CommPortIdentifier.getPortIdentifier ("COM14"); > ?OpenThread t1 = new OpenThread (" one ", cpiCom1); > ?OpenThread t2 = new OpenThread (" two ", cpiCom1); > ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); > ?t1.start(); > ?t2.start(); > ?t3.start(); // comment this out >and it runs with (expected) PortInUseException > ?} catch (Exception e) { > ?e.printStackTrace(); > ?} > ?} >} > >class OpenThread extends Thread { > ?String name; > ?CommPortIdentifier cpi; > ?CommPort cp; > ?public OpenThread (String name, CommPortIdentifier cpi) { > ? this.name = name; > ?this.cpi = cpi; > ?System.out.println >(System.currentTimeMillis() + name + " thread >created"); > ?} > ?public void run () { > ?try { > ?System.out.println >(System.currentTimeMillis() + name + " opening"); > ?cp = cpi.open(name, 2000); > ?System.out.println >(System.currentTimeMillis() + name + " opened - >sleeping"); > ?sleep (2000); // do the serial comms with the device. > ?System.out.println >(System.currentTimeMillis() + name + " slept - >closing"); > ?cp.close(); > ?System.out.println >(System.currentTimeMillis() + name + " closed - >exiting"); > ?} catch (Exception e) { > System.out.println ("Error in thread: " + name ); > ?e.printStackTrace(); > ?} > ?} >} > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Mar 9 06:37:45 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 Mar 2007 06:37:45 -0700 (MST) Subject: [Rxtx] rxtx: tru64 unix make fails In-Reply-To: References: Message-ID: On Fri, 9 Mar 2007, "Giuseppe Marchese" wrote: > Sorry for delay. > ? > This is log for ./configure and make > error. > ? > thanks for attention > ? > Make: '%.java,$(TOP)/$(CLASSDEST)/%.class,$(wildcard $(SPATH)/*.java)': extra chars.? > Stop. > Hi Giuseppe You need to use GNU make with the Makefile. I suspect the tru64 make is not happy with those rules. > configure: exit 0 Looks like configure is fairly happy. From tjarvi at qbang.org Sat Mar 10 07:43:51 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 07:43:51 -0700 (MST) Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi Doug I have very little time to look into this further but what we could do is open up an rxtx 3 devel branch in which a proof of concept could be worked on. It could be the proof of concept for a JSR others including Sun could look at/work on or parts of it could be recycled in a JSR. I'm working very hard on rxtx right now but it does not show. I'm looking at win64, mac intel/ppc, usb bluetooth and usb serial dongles. Some are going to be more tested than others but they are all on the plate. I'll be pushing all the fixes upstream when they are done. So I'm very busy in 2.1 but we could open a new branch. On Fri, 9 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > The deadlock issue is one that I have been thinking about > for some time now. > It seems to me that we need a resource manager that enables assignment > to a known process. > > The one thing that seems important about serial > ports is that two applications should not use the > same serial port at the same time. When this > happens, it throws an exception. > OK. > > The exception is a response to a lock condition that > arises from an unavailable resource. > > An abstract implementation (not born of native methods) might > assign a serial port to an application, until the > application releases it (or is forced to release > it by some kill mechanism). > > Some resources (like a registry) can be reused. > But others, like the serial port, > cannot. > > In the case of the serial port, we would like, I think, to > have the flyweight design pattern > without sharing and with object assignment tracking. > A means of breaking deadlock (like a leasing > mechanism) seems very useful, to me. > > My guess is that we can serialize the state of the Parametric Singleton Pattern > (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) > into the Preferences of the System. Preferences.systemRoot() might help > with that. When a resource is checked out, the lease time and owner are > listed. A thread that does this can be killed, but applications outside of Java > are problematic. > > There is a compelling problem here. It is not just serial ports. > Sound cards, cameras, microphones, files, tape drives, etc. All are consumed > resources that are assigned to an application (or > user) and deprive other applications, > or users, from use. > > What, if anything, should we do? At present we throw PortInUseExceptions. > Is that it? > Can we do better? > OK, the port is in use. Now what? > Do I have to be root to go remove lock files and kill applications? > Is there a better way? > > Thanks! > - Doug > >> I've just struck an issue using rxtx in a multi-threaded environment: >> >> If I have 3 threads trying to open *the same* >> comm-port I get a deadlock in >> CommPortIdentifier.open >> If I have just 2, it works fine - I get a >> PortInUseException which is nice and I can >> handle it. >> >> The 3 thread->deadlock thing is causing me issues. >> (Sample code below). >> >> This is from the java thread-dump >> >> Found one Java-level deadlock: >> ============================= >> "Thread-2": >> waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), >> which is held by "Thread-1" >> "Thread-1": >> waiting to lock monitor 0x0003e9cc (object >> 0x2450e108, a gnu.io.CommPortIdentifier ), >> which is held by "Thread-2" >> >> Java stack information for the threads listed above: >> =================================================== >> "Thread-2": >> at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) >> - waiting to lock <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> "Thread-1": >> at java.lang.Object.wait(Native Method) >> - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) >> - locked <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> >> >> (Apart from this, rxtx is working fantastically for us). >> >> I'm thinking I'll have to implement some sort of >> locking mechanism that *doesn't* use java >> synchronization to prevent this situation. >> (Which doesn't sound like a good idea to me). >> >> Any ideas? >> >> Thanks, >> >> Greg Hanna >> >> ============= RXTXLockTest.java ======================================== >> >> import gnu.io.CommPort; >> import gnu.io.CommPortIdentifier; >> >> /** >> * @author Greg Hanna >> * Minimal code to create a deadlock with rxtx in multithreaded open >> */ >> public class RXTXLockTest { >> ? >> ?public static void main(String[] args) { >> ?try { >> ?CommPortIdentifier cpiCom1 = >> CommPortIdentifier.getPortIdentifier ("COM14"); >> ?OpenThread t1 = new OpenThread (" one ", cpiCom1); >> ?OpenThread t2 = new OpenThread (" two ", cpiCom1); >> ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); >> ?t1.start(); >> ?t2.start(); >> ?t3.start(); // comment this out >> and it runs with (expected) PortInUseException >> ?} catch (Exception e) { >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> class OpenThread extends Thread { >> ?String name; >> ?CommPortIdentifier cpi; >> ?CommPort cp; >> ?public OpenThread (String name, CommPortIdentifier cpi) { >> ? this.name = name; >> ?this.cpi = cpi; >> ?System.out.println >> (System.currentTimeMillis() + name + " thread >> created"); >> ?} >> ?public void run () { >> ?try { >> ?System.out.println >> (System.currentTimeMillis() + name + " opening"); >> ?cp = cpi.open(name, 2000); >> ?System.out.println >> (System.currentTimeMillis() + name + " opened - >> sleeping"); >> ?sleep (2000); // do the serial comms with the device. >> ?System.out.println >> (System.currentTimeMillis() + name + " slept - >> closing"); >> ?cp.close(); >> ?System.out.println >> (System.currentTimeMillis() + name + " closed - >> exiting"); >> ?} catch (Exception e) { >> System.out.println ("Error in thread: " + name ); >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 mm at UDel.Edu Sat Mar 10 14:48:32 2007 From: mm at UDel.Edu (Mike Markowski) Date: Sat, 10 Mar 2007 16:48:32 -0500 Subject: [Rxtx] rxtx and Sun's comm api Message-ID: <45F327B0.2060004@udel.edu> Hi all, I joined the list a few days ago and apologize for what is likely a frequently asked question, though I haven't yet found it anywhere. I learned about rxtx.org through the readme on Sun's version 2 of their comms api. They give recommendations in that readme regarding how a better comms api should be written. Is this the aim of rxtx.org? I wrote an app on my linux box using the Sun comms api (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the fact that only linux and Solaris are supported. So I'm glad to find rxtx.org and am just reading up on how make the conversion so Windows users will be able to run the program as well. At the same time I'm just curious if rxtx.org and Sun are both heading in the same direction. Thanks for any background or historical info. Feel free to point me to any www pages if my googling has just completely missed the target! Thanks again, Mike From tjarvi at qbang.org Sat Mar 10 15:35:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 15:35:25 -0700 (MST) Subject: [Rxtx] rxtx and Sun's comm api In-Reply-To: <45F327B0.2060004@udel.edu> References: <45F327B0.2060004@udel.edu> Message-ID: On Sat, 10 Mar 2007, Mike Markowski wrote: > Hi all, > > I joined the list a few days ago and apologize for what is likely a > frequently asked question, though I haven't yet found it anywhere. I > learned about rxtx.org through the readme on Sun's version 2 of their > comms api. They give recommendations in that readme regarding how a > better comms api should be written. Is this the aim of rxtx.org? > > I wrote an app on my linux box using the Sun comms api > (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the > fact that only linux and Solaris are supported. So I'm glad to find > rxtx.org and am just reading up on how make the conversion so Windows > users will be able to run the program as well. At the same time I'm > just curious if rxtx.org and Sun are both heading in the same direction. > > Thanks for any background or historical info. Feel free to point me to > any www pages if my googling has just completely missed the target! > I do not have any news (good or bad) concerning RXTX and Sun working together but perhaps others here do. The main goal of RXTX is to expose POSIX termios interfaces to java users. The future support of javax.comm is questionable. We do not have resources for everything. gnu.io (RXTX 2.1) will be supported going forward and functions the same as CommAPI 2.0. If you have control of the source code you are working with, I would not advise using CommAPI 2.0 javax.comm. We do support CommAPI 2.0 javax.comm for older applications but I do not think that will last much longer for practical reasons. The download interest in CommAPI 2.0 javax.comm support is becomming negligible on this end. There has been discussion of a JSR effort but I do not know of any status change since it was mentioned. One problem with a JSR is that even a light weight process is going to be difficult for RXTX at this time. Maybe that will change in the future but then again it may not. For now, we are just going forward 'as is' in rxtx 2.1 with package gnu.io while trying as a secondary effort to backport the changes to rxtx 2.0 for javax.comm support for users that do not have a choice. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Mar 11 07:19:40 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 11 Mar 2007 08:19:40 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: Hi All, I have been a proponent of a JSR that makes use of RXTX. I have executed the proper agreements with Sun. At this point we are in the: Early Draft Review of Draft Specifications Stage. The best thing to do is to enter the quiet period and create a specification. The question of exactly how we, as a group, want to approach this problem, remains open. Typically, we should have both a specification and a reference implementation. Thus, it would be to our best advantage to have a nice, stable, cross platform RXTX distro that adheres to the groups specification. Now, from a specification standpoint, my personal view on the matter is that we create a series of interfaces, with nice documentation (or at least javadoc). Is this a good idea? Should we have a pure interface specification for the communication API? There are several issues, in my mind, which still weigh on us. Hot-pluggable dongles, long discovery process on pop-up ports, lack of uniformity on device names, lack of uniformity on locking, a precise understanding of how the SerialPortResourceManager works (or even if we should have one). The more questions we answer in our reference implementation, the better our specification will get. RXTX is a good working prototype, but, I don't know if that is what we want to use for a specification. Here is what I have for a CommPortInterface: */ public interface CommPortInterface { /** * @return a string representation of this port. */ String toString(); /** * Gets the name of the communications port. This name should correspond to * something the user can identify, like the label on the hardware. * @return name of the port */ String getName(); /** * @return an input stream that can be used to read data from the * communications port. If the port doesn't support reading data, this * method returns null. *

* The blocking behaviour of this input stream depends on the threshold * and timeout values, as shown below for a read buffer size of n * bytes: * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ThresholdTimeoutBlocking behaviour
StateValueStateValue
disableddisabledblock until data is available
enabledm bytesdisabledblock until min(m, n) bytes are available
disabledenabledt msblock for t ms or until data is available
enabledm bytesenabledt msblock for t ms or until min(m, n) bytes are * available
* @throws java.io.IOException */ InputStream getInputStream() throws IOException; /** * @return an output stream that can be used to send data to the * communications port. If the port doesn't support sending data, this * method returns null. * @throws java.io.IOException */ OutputStream getOutputStream() throws IOException; /** * Closes this communications port. * All PortOwnershipListeners will be? * notified of this change of ownership. Further method calls on this? * object will throw IllegalStateException. Further calls on the? * associated InputStream or OutputStream will throw IOException. *

* Close does not block. Undelivered data is discarded. Blocked read and? * write operations are aborted if the underlying operating systems? * supports an IO abort mechanism. To await the delivery of undelivered? * data call OutputStream.flush() or OutputStream.close() before calling? * Port.close(). */ void close(); /** * Enables receive threshold. * When the specified threshold number of bytes are retrieved, read will * return immediately. * * @param thresh the number of bytes in the input buffer * @throws gnu.io.UnsupportedCommOperationException * if receive threshold is * not supported by the driver * @see #disableReceiveThreshold */ void enableReceiveThreshold(int thresh) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive threshold. * * @see #enableReceiveThreshold */ void disableReceiveThreshold(); /** * @return true if receive threshold is enabled. * * @see #enableReceiveThreshold */ boolean isReceiveThresholdEnabled(); /** * @return the receive threshold value. If receive threshold is diabled * or not supported, this value is meaningless. * * @see #enableReceiveThreshold */ int getReceiveThreshold(); /** * Enables receive timeout. * When the specified number of milliseconds have elapsed, read will * return immediately. * * @param rcvTimeout the number of milliseconds to block for * @throws gnu.io.UnsupportedCommOperationException * if receive timeout is * not supported by the driver * @see #disableReceiveTimeout */ void enableReceiveTimeout(int rcvTimeout) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive timeout. * * @see #enableReceiveTimeout */ void disableReceiveTimeout(); /** * @return true if receive timeout is enabled. * * @see #enableReceiveTimeout */ boolean isReceiveTimeoutEnabled(); /** * @return the receive timeout value. If receive timeout is diabled * or not supported, this value is meaningless. * * @see #enableReceiveTimeout */ int getReceiveTimeout(); /** * Enables receive framing. * The supplied byte value in the input suggests the end of the received * frame, and read returns immediately. Only the low 8 bits of the * supplied value are significant. * * @param framingByte the frame delimiter * @throws gnu.io.UnsupportedCommOperationException * if receive framing is * not supported by the driver * @see #disableReceiveFraming */ void enableReceiveFraming(int framingByte) throws UnsupportedCommOperationException; /** * Disables receive framing. * * @see #enableReceiveFraming */ void disableReceiveFraming(); /** * @return true if receive framing is enabled. * * @see #enableReceiveFraming */ boolean isReceiveFramingEnabled(); /** * @return true if receive framing byte. If receive framing is diabled * or not supported, this value is meaningless. * * @see #enableReceiveFraming */ int getReceiveFramingByte(); /** * Sets the input buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setInputBufferSize(int size); /** * @return the input buffer size. * The driver may choose not to report correct values. */ int getInputBufferSize(); /** * Sets the output buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setOutputBufferSize(int size); /** * @return the output buffer size. * The driver may choose not to report correct values. */ int getOutputBufferSize(); } What do you think of that? Note the wishy washy nature of the spec: The driver may choose to ignore this method. Is that good enough for us? Thanks! - Doug From ra85551 at gmail.com Sun Mar 11 08:44:45 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Sun, 11 Mar 2007 17:44:45 +0300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hello, world! I am writing application that communicates with modem via AT commands. My OS is Linux Kubuntu Feisty Herd, to ensure that my application will run properly under Windows XP I installed VMWare server. When I tried to send AT command and evaluate modem answer under WinXP @ VMWare server, I actually didn't receive anything. I think that VM settings are right, because I do can communicate with modem by using standard HyperTerminall as well as I can do on native Windows. So, why RXTX doesn't work under VM, but works under Linux and pure Windows XP (i tested it there) well? The send/receive method code follows. private String sendATCommand(String command, final String waitFor, final boolean isRegex, boolean isAddCRLF, long timeout) throws BeaconConnectException { final long POLL_PERIOD = 100; final int BUFFER_SIZE = 512; final byte[] buffer = new byte[BUFFER_SIZE]; final InputStream serialInput; final OutputStream serialOutput; try { serialInput = serialPort.getInputStream(); if (command != null) { serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } } catch (IOException e) { throw new MyException("serial I/O error"); } TimerTask task = new TimerTask() { int offset = 0; int bytesRead; public synchronized void run() { try { if (serialInput.available() > 0) { bytesRead = serialInput.read(buffer, offset, BUFFER_SIZE - offset); } else { return; } } catch (IOException e) { // do nothing - maybe next time we'll read something } offset += bytesRead; if (waitFor != null) { String temporary = new String(buffer, 0, offset).trim(); if (isRegex && temporary.matches(waitFor) || temporary.contains(waitFor)) { cancel(); notify(); } } } }; Timer timer = new Timer(); timer.schedule(task, POLL_PERIOD, POLL_PERIOD); synchronized (task) { try { task.wait(timeout); task.cancel(); } catch (InterruptedException e) { } } //Cut off leading and trailing CRs, LFs and zeroes String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); System.out.println(response); return response; } -- Pavel Parkhomenko From tjarvi at qbang.org Sun Mar 11 11:48:22 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:48:22 -0600 (MDT) Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: On Sun, 11 Mar 2007, Pavel Parkhomenko wrote: > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. > > private String sendATCommand(String command, final String waitFor, > final boolean isRegex, boolean isAddCRLF, long timeout) > throws BeaconConnectException > { > final long POLL_PERIOD = 100; > final int BUFFER_SIZE = 512; > final byte[] buffer = new byte[BUFFER_SIZE]; > final InputStream serialInput; > final OutputStream serialOutput; > try > { > serialInput = serialPort.getInputStream(); > if (command != null) > { > serialOutput = serialPort.getOutputStream(); > if (isAddCRLF) > { > command += "\r\n"; > } > System.out.println(command); > serialOutput.write(command.getBytes()); > } > } > catch (IOException e) > { > throw new MyException("serial I/O error"); > } > > TimerTask task = new TimerTask() > { > int offset = 0; > int bytesRead; > public synchronized void run() > { > try > { > if (serialInput.available() > 0) > { > bytesRead = serialInput.read(buffer, offset, > BUFFER_SIZE - offset); > } > else > { > return; > } > } > catch (IOException e) > { > // do nothing - maybe next time we'll read something > } > offset += bytesRead; > if (waitFor != null) > { > String temporary = new String(buffer, 0, offset).trim(); > if (isRegex && temporary.matches(waitFor) || > temporary.contains(waitFor)) > { > cancel(); > notify(); > } > } > } > }; > > Timer timer = new Timer(); > timer.schedule(task, POLL_PERIOD, POLL_PERIOD); > synchronized (task) { > try > { > task.wait(timeout); > task.cancel(); > } > catch (InterruptedException e) > { > } > } > //Cut off leading and trailing CRs, LFs and zeroes > String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); > System.out.println(response); > return response; > } > > > Hi Pavel VMWare should not be a problem. I've used it in the past - though not with a modem. Make sure nothing else is using the modem. Then look in the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an example that should work. Note that modems could care less what OS is on top. If you are trying to match new lines to the OS and sending it to the mode for AT commands, thats probably a mistake. Also it would not hurt to print out the individual bytes that you are sending to make sure they did not get mangled along the path. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 11:55:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:55:48 -0600 (MDT) Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: On Sun, 11 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > I have been a proponent of a JSR that makes > use of RXTX. I have executed the proper agreements with Sun. > > At this point we are in the: > Early Draft Review of Draft Specifications Stage. > > The best thing to do is to enter the quiet period and create > a specification. The question of exactly how we, as a group, > want to approach this problem, remains open. > > Typically, we should have both a specification and a reference > implementation. Thus, it would be to our best advantage to have > a nice, stable, cross platform RXTX distro that adheres to the > groups specification. > > Now, from a specification standpoint, my personal view on the matter is > that we create a series of interfaces, with nice documentation (or at least > javadoc). > > Is this a good idea? Should we have a pure interface specification for > the communication API? > > There are several issues, in my mind, which still weigh on us. > Hot-pluggable dongles, long discovery process on pop-up ports, > lack of uniformity on device names, lack of uniformity on locking, > a precise understanding of how the SerialPortResourceManager > works (or even if we should have one). > > The more questions we answer in our reference implementation, the > better our specification will get. RXTX is a good working prototype, > but, I don't know if that is what we want to use for a specification. > > Here is what I have for a CommPortInterface: > */ > public interface CommPortInterface { Hi Doug, I can start going through the method interfaces later this week and giving feedback. I would suggest that the JSR should not be too generic in nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel drivers that intend to look like EIA232 ports at the kernel driver level. some ideas: EIA232PortInterface TermiosInterface SerialPortInterface Something that differentiates this from thing like USB, I2C, ... which should not have to deal with legacy serial claiming to be the comm api. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 12:52:19 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 12:52:19 -0600 (MDT) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: No news is good news with these posts. I'll start the process of pinging legal a week from Monday on my end if nobody has objections to the proposal. I just want to make sure everyone has time to raise objections. Obviously, anyone can fork from a previous version if they don't like the new license. I suspect we can avoid that though. On Sun, 4 Mar 2007, Trent Jarvi wrote: > > For those that are wondering what is going on here, this > next bit is the meat of the changes. We agreed a long time > ago to put this disclaimer in. We did a so so job. It was > in rxtx 2.0, not well written, ... So some groups using > rxtx that would like to ship rxtx so users don't need to > download, install, go to the mail-list to find why it failed, > ... Then their legal teams tell them section 5 paragraph 2 > is a show stopper. > > That was never the intent. > > > Now going through what remains... > >> and might need a (TM) suffix to make Sun happy. > > Added disclaimer at the ended 'all trademarks belong...' > >> * Line #15ff - static vs. dynamic linking - you did >> not transcribe the text from the "controlled >> interface exception" when writing this text - and >> this was good so, because these terms originally >> refer to the GPL rather than the LGPL. I think though, >> that these 4 lines are the most important ones and >> should thus be really really clear. I hope that I >> meet your original intent with the following >> suggestions: >> 1.) Instead of "A program.." it would be better to >> say "An exectuable.." in order to be closer to >> the LGPL text. > > OK. As you can see I was trying to adjust GNU text there > for the LGPL. > >> 2.) It would be better to say .. "by being dynamically >> linked with it" to clearly indicate that dynamic >> linking is meant. The matter of compilation is >> already covered by the LGPL so mentioning it again >> just leads to confusion. > > used dynamically linked terminology. > >> 3.) It would be better to say .. "is considered a >> work that uses the library in contrast to section >> 5 of the LGPL, so the terms of the LGPL do not >> apply to the resulting executable". > > I tried to address this more upfront with an intent statement. > Let me know if you have problems with it. I also tried to > make it a little more clear what was derived from the GNU > solution by moving the link location closer to GNU's suggestion. > >> >> Note that LGPL section 5 says: ..."is called a >> "work that uses the Library". Such a work, in isolation, >> is not a derivative work of the Library, and therefore >> falls outside the scope of this License." >> The next paragraph of the LGPL is exactly the problematic >> one that I hope is clarified by the exception terms you >> give. >> > > Thats the intent. Here is the combined fixes. Note that only the > material in /*-- --*/ is being touched. The new GPL license is > there but unmodified. > > > ------------------------ begin proposed new license ------------------- > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Lesser General Public > | License as published by the Free Software Foundation; either > | version 2.1 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Lesser General Public License for more details. > | > | An executable that contains no derivative of any portion of RXTX, but > | is designed to work with RXTX by being dynamically linked with it, > | is considered a "work that uses the Library" subject to the terms and > | conditions of the GNU Lesser General Public License. > | > | The following has been added to the RXTX License to remove > | any confusion about linking to RXTX. We want to allow in part what > | section 5, paragraph 2 of the LGPL does not permit in the special > | case of linking over a controlled interface. The intent is to add a > | Java Specification Request or standards body defined interface in the > | future as another exception but one is not currently available. > | > | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface > | > | As a special exception, the copyright holders of RXTX give you > | permission to link RXTX with independent modules that communicate with > | RXTX solely through the Sun Microsytems CommAPI interface version 2, > | regardless of the license terms of these independent modules, and to copy > | and distribute the resulting combined work under terms of your choice, > | provided that every copy of the combined work is accompanied by a complete > | copy of the source code of RXTX (the version of RXTX used to produce the > | combined work), being distributed under the terms of the GNU Lesser General > | Public License plus this exception. An independent module is a > | module which is not derived from or based on RXTX. > | > | Note that people who make modified versions of RXTX are not obligated > | to grant this special exception for their modified versions; it is > | their choice whether to do so. The GNU Lesser General Public License > | gives permission to release a modified version without this exception; this > | exception also makes it possible to release a modified version which > | carries forward this exception. > | > | You should have received a copy of the GNU Lesser General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > | All trademarks belong to their respective owners. > --------------------------------------------------------------------------*/ > > The original GNU Lesser General Public License Follows. > > > GNU LESSER GENERAL PUBLIC LICENSE > Version 2.1, February 1999 > > Copyright (C) 1991, 1999 Free Software Foundation, Inc. > 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > Everyone is permitted to copy and distribute verbatim copies > of this license document, but changing it is not allowed. > > [This is the first released version of the Lesser GPL. It also counts > as the successor of the GNU Library Public License, version 2, hence > the version number 2.1.] > > Preamble > > The licenses for most software are designed to take away your > freedom to share and change it. By contrast, the GNU General Public > Licenses are intended to guarantee your freedom to share and change > free software--to make sure the software is free for all its users. > > This license, the Lesser General Public License, applies to some > specially designated software packages--typically libraries--of the > Free Software Foundation and other authors who decide to use it. You > can use it too, but we suggest you first think carefully about whether > this license or the ordinary General Public License is the better > strategy to use in any particular case, based on the explanations below. > > When we speak of free software, we are referring to freedom of use, > not price. Our General Public Licenses are designed to make sure that > you have the freedom to distribute copies of free software (and charge > for this service if you wish); that you receive source code or can get > it if you want it; that you can change the software and use pieces of > it in new free programs; and that you are informed that you can do > these things. > > To protect your rights, we need to make restrictions that forbid > distributors to deny you these rights or to ask you to surrender these > rights. These restrictions translate to certain responsibilities for > you if you distribute copies of the library or if you modify it. > > For example, if you distribute copies of the library, whether gratis > or for a fee, you must give the recipients all the rights that we gave > you. You must make sure that they, too, receive or can get the source > code. If you link other code with the library, you must provide > complete object files to the recipients, so that they can relink them > with the library after making changes to the library and recompiling > it. And you must show them these terms so they know their rights. > > We protect your rights with a two-step method: (1) we copyright the > library, and (2) we offer you this license, which gives you legal > permission to copy, distribute and/or modify the library. > > To protect each distributor, we want to make it very clear that > there is no warranty for the free library. Also, if the library is > modified by someone else and passed on, the recipients should know > that what they have is not the original version, so that the original > author's reputation will not be affected by problems that might be > introduced by others. > > Finally, software patents pose a constant threat to the existence of > any free program. We wish to make sure that a company cannot > effectively restrict the users of a free program by obtaining a > restrictive license from a patent holder. Therefore, we insist that > any patent license obtained for a version of the library must be > consistent with the full freedom of use specified in this license. > > Most GNU software, including some libraries, is covered by the > ordinary GNU General Public License. This license, the GNU Lesser > General Public License, applies to certain designated libraries, and > is quite different from the ordinary General Public License. We use > this license for certain libraries in order to permit linking those > libraries into non-free programs. > > When a program is linked with a library, whether statically or using > a shared library, the combination of the two is legally speaking a > combined work, a derivative of the original library. The ordinary > General Public License therefore permits such linking only if the > entire combination fits its criteria of freedom. The Lesser General > Public License permits more lax criteria for linking other code with > the library. > > We call this license the "Lesser" General Public License because it > does Less to protect the user's freedom than the ordinary General > Public License. It also provides other free software developers Less > of an advantage over competing non-free programs. These disadvantages > are the reason we use the ordinary General Public License for many > libraries. However, the Lesser license provides advantages in certain > special circumstances. > > For example, on rare occasions, there may be a special need to > encourage the widest possible use of a certain library, so that it becomes > a de-facto standard. To achieve this, non-free programs must be > allowed to use the library. A more frequent case is that a free > library does the same job as widely used non-free libraries. In this > case, there is little to gain by limiting the free library to free > software only, so we use the Lesser General Public License. > > In other cases, permission to use a particular library in non-free > programs enables a greater number of people to use a large body of > free software. For example, permission to use the GNU C Library in > non-free programs enables many more people to use the whole GNU > operating system, as well as its variant, the GNU/Linux operating > system. > > Although the Lesser General Public License is Less protective of the > users' freedom, it does ensure that the user of a program that is > linked with the Library has the freedom and the wherewithal to run > that program using a modified version of the Library. > > The precise terms and conditions for copying, distribution and > modification follow. Pay close attention to the difference between a > "work based on the library" and a "work that uses the library". The > former contains code derived from the library, whereas the latter must > be combined with the library in order to run. > > GNU LESSER GENERAL PUBLIC LICENSE > TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION > > 0. This License Agreement applies to any software library or other > program which contains a notice placed by the copyright holder or > other authorized party saying it may be distributed under the terms of > this Lesser General Public License (also called "this License"). > Each licensee is addressed as "you". > > A "library" means a collection of software functions and/or data > prepared so as to be conveniently linked with application programs > (which use some of those functions and data) to form executables. > > The "Library", below, refers to any such software library or work > which has been distributed under these terms. A "work based on the > Library" means either the Library or any derivative work under > copyright law: that is to say, a work containing the Library or a > portion of it, either verbatim or with modifications and/or translated > straightforwardly into another language. (Hereinafter, translation is > included without limitation in the term "modification".) > > "Source code" for a work means the preferred form of the work for > making modifications to it. For a library, complete source code means > all the source code for all modules it contains, plus any associated > interface definition files, plus the scripts used to control compilation > and installation of the library. > > Activities other than copying, distribution and modification are not > covered by this License; they are outside its scope. The act of > running a program using the Library is not restricted, and output from > such a program is covered only if its contents constitute a work based > on the Library (independent of the use of the Library in a tool for > writing it). Whether that is true depends on what the Library does > and what the program that uses the Library does. > > 1. You may copy and distribute verbatim copies of the Library's > complete source code as you receive it, in any medium, provided that > you conspicuously and appropriately publish on each copy an > appropriate copyright notice and disclaimer of warranty; keep intact > all the notices that refer to this License and to the absence of any > warranty; and distribute a copy of this License along with the > Library. > > You may charge a fee for the physical act of transferring a copy, > and you may at your option offer warranty protection in exchange for a > fee. > > 2. You may modify your copy or copies of the Library or any portion > of it, thus forming a work based on the Library, and copy and > distribute such modifications or work under the terms of Section 1 > above, provided that you also meet all of these conditions: > > a) The modified work must itself be a software library. > > b) You must cause the files modified to carry prominent notices > stating that you changed the files and the date of any change. > > c) You must cause the whole of the work to be licensed at no > charge to all third parties under the terms of this License. > > d) If a facility in the modified Library refers to a function or a > table of data to be supplied by an application program that uses > the facility, other than as an argument passed when the facility > is invoked, then you must make a good faith effort to ensure that, > in the event an application does not supply such function or > table, the facility still operates, and performs whatever part of > its purpose remains meaningful. > > (For example, a function in a library to compute square roots has > a purpose that is entirely well-defined independent of the > application. Therefore, Subsection 2d requires that any > application-supplied function or table used by this function must > be optional: if the application does not supply it, the square > root function must still compute square roots.) > > These requirements apply to the modified work as a whole. If > identifiable sections of that work are not derived from the Library, > and can be reasonably considered independent and separate works in > themselves, then this License, and its terms, do not apply to those > sections when you distribute them as separate works. But when you > distribute the same sections as part of a whole which is a work based > on the Library, the distribution of the whole must be on the terms of > this License, whose permissions for other licensees extend to the > entire whole, and thus to each and every part regardless of who wrote > it. > > Thus, it is not the intent of this section to claim rights or contest > your rights to work written entirely by you; rather, the intent is to > exercise the right to control the distribution of derivative or > collective works based on the Library. > > In addition, mere aggregation of another work not based on the Library > with the Library (or with a work based on the Library) on a volume of > a storage or distribution medium does not bring the other work under > the scope of this License. > > 3. You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. To do > this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version 2, > instead of to this License. (If a newer version than version 2 of the > ordinary GNU General Public License has appeared, then you can specify > that version instead if you wish.) Do not make any other change in > these notices. > > Once this change is made in a given copy, it is irreversible for > that copy, so the ordinary GNU General Public License applies to all > subsequent copies and derivative works made from that copy. > > This option is useful when you wish to copy part of the code of > the Library into a program that is not a library. > > 4. You may copy and distribute the Library (or a portion or > derivative of it, under Section 2) in object code or executable form > under the terms of Sections 1 and 2 above provided that you accompany > it with the complete corresponding machine-readable source code, which > must be distributed under the terms of Sections 1 and 2 above on a > medium customarily used for software interchange. > > If distribution of object code is made by offering access to copy > from a designated place, then offering equivalent access to copy the > source code from the same place satisfies the requirement to > distribute the source code, even though third parties are not > compelled to copy the source along with the object code. > > 5. A program that contains no derivative of any portion of the > Library, but is designed to work with the Library by being compiled or > linked with it, is called a "work that uses the Library". Such a > work, in isolation, is not a derivative work of the Library, and > therefore falls outside the scope of this License. > > However, linking a "work that uses the Library" with the Library > creates an executable that is a derivative of the Library (because it > contains portions of the Library), rather than a "work that uses the > library". The executable is therefore covered by this License. > Section 6 states terms for distribution of such executables. > > When a "work that uses the Library" uses material from a header file > that is part of the Library, the object code for the work may be a > derivative work of the Library even though the source code is not. > Whether this is true is especially significant if the work can be > linked without the Library, or if the work is itself a library. The > threshold for this to be true is not precisely defined by law. > > If such an object file uses only numerical parameters, data > structure layouts and accessors, and small macros and small inline > functions (ten lines or less in length), then the use of the object > file is unrestricted, regardless of whether it is legally a derivative > work. (Executables containing this object code plus portions of the > Library will still fall under Section 6.) > > Otherwise, if the work is a derivative of the Library, you may > distribute the object code for the work under the terms of Section 6. > Any executables containing that work also fall under Section 6, > whether or not they are linked directly with the Library itself. > > 6. As an exception to the Sections above, you may also combine or > link a "work that uses the Library" with the Library to produce a > work containing portions of the Library, and distribute that work > under terms of your choice, provided that the terms permit > modification of the work for the customer's own use and reverse > engineering for debugging such modifications. > > You must give prominent notice with each copy of the work that the > Library is used in it and that the Library and its use are covered by > this License. You must supply a copy of this License. If the work > during execution displays copyright notices, you must include the > copyright notice for the Library among them, as well as a reference > directing the user to the copy of this License. Also, you must do one > of these things: > > a) Accompany the work with the complete corresponding > machine-readable source code for the Library including whatever > changes were used in the work (which must be distributed under > Sections 1 and 2 above); and, if the work is an executable linked > with the Library, with the complete machine-readable "work that > uses the Library", as object code and/or source code, so that the > user can modify the Library and then relink to produce a modified > executable containing the modified Library. (It is understood > that the user who changes the contents of definitions files in the > Library will not necessarily be able to recompile the application > to use the modified definitions.) > > b) Use a suitable shared library mechanism for linking with the > Library. A suitable mechanism is one that (1) uses at run time a > copy of the library already present on the user's computer system, > rather than copying library functions into the executable, and (2) > will operate properly with a modified version of the library, if > the user installs one, as long as the modified version is > interface-compatible with the version that the work was made with. > > c) Accompany the work with a written offer, valid for at > least three years, to give the same user the materials > specified in Subsection 6a, above, for a charge no more > than the cost of performing this distribution. > > d) If distribution of the work is made by offering access to copy > from a designated place, offer equivalent access to copy the above > specified materials from the same place. > > e) Verify that the user has already received a copy of these > materials or that you have already sent this user a copy. > > For an executable, the required form of the "work that uses the > Library" must include any data and utility programs needed for > reproducing the executable from it. However, as a special exception, > the materials to be distributed need not include anything that is > normally distributed (in either source or binary form) with the major > components (compiler, kernel, and so on) of the operating system on > which the executable runs, unless that component itself accompanies > the executable. > > It may happen that this requirement contradicts the license > restrictions of other proprietary libraries that do not normally > accompany the operating system. Such a contradiction means you cannot > use both them and the Library together in an executable that you > distribute. > > 7. You may place library facilities that are a work based on the > Library side-by-side in a single library together with other library > facilities not covered by this License, and distribute such a combined > library, provided that the separate distribution of the work based on > the Library and of the other library facilities is otherwise > permitted, and provided that you do these two things: > > a) Accompany the combined library with a copy of the same work > based on the Library, uncombined with any other library > facilities. This must be distributed under the terms of the > Sections above. > > b) Give prominent notice with the combined library of the fact > that part of it is a work based on the Library, and explaining > where to find the accompanying uncombined form of the same work. > > 8. You may not copy, modify, sublicense, link with, or distribute > the Library except as expressly provided under this License. Any > attempt otherwise to copy, modify, sublicense, link with, or > distribute the Library is void, and will automatically terminate your > rights under this License. However, parties who have received copies, > or rights, from you under this License will not have their licenses > terminated so long as such parties remain in full compliance. > > 9. You are not required to accept this License, since you have not > signed it. However, nothing else grants you permission to modify or > distribute the Library or its derivative works. These actions are > prohibited by law if you do not accept this License. Therefore, by > modifying or distributing the Library (or any work based on the > Library), you indicate your acceptance of this License to do so, and > all its terms and conditions for copying, distributing or modifying > the Library or works based on it. > > 10. Each time you redistribute the Library (or any work based on the > Library), the recipient automatically receives a license from the > original licensor to copy, distribute, link with or modify the Library > subject to these terms and conditions. You may not impose any further > restrictions on the recipients' exercise of the rights granted herein. > You are not responsible for enforcing compliance by third parties with > this License. > > 11. If, as a consequence of a court judgment or allegation of patent > infringement or for any other reason (not limited to patent issues), > conditions are imposed on you (whether by court order, agreement or > otherwise) that contradict the conditions of this License, they do not > excuse you from the conditions of this License. If you cannot > distribute so as to satisfy simultaneously your obligations under this > License and any other pertinent obligations, then as a consequence you > may not distribute the Library at all. For example, if a patent > license would not permit royalty-free redistribution of the Library by > all those who receive copies directly or indirectly through you, then > the only way you could satisfy both it and this License would be to > refrain entirely from distribution of the Library. > > If any portion of this section is held invalid or unenforceable under any > particular circumstance, the balance of the section is intended to apply, > and the section as a whole is intended to apply in other circumstances. > > It is not the purpose of this section to induce you to infringe any > patents or other property right claims or to contest validity of any > such claims; this section has the sole purpose of protecting the > integrity of the free software distribution system which is > implemented by public license practices. Many people have made > generous contributions to the wide range of software distributed > through that system in reliance on consistent application of that > system; it is up to the author/donor to decide if he or she is willing > to distribute software through any other system and a licensee cannot > impose that choice. > > This section is intended to make thoroughly clear what is believed to > be a consequence of the rest of this License. > > 12. If the distribution and/or use of the Library is restricted in > certain countries either by patents or by copyrighted interfaces, the > original copyright holder who places the Library under this License may add > an explicit geographical distribution limitation excluding those countries, > so that distribution is permitted only in or among countries not thus > excluded. In such case, this License incorporates the limitation as if > written in the body of this License. > > 13. The Free Software Foundation may publish revised and/or new > versions of the Lesser General Public License from time to time. > Such new versions will be similar in spirit to the present version, > but may differ in detail to address new problems or concerns. > > Each version is given a distinguishing version number. If the Library > specifies a version number of this License which applies to it and > "any later version", you have the option of following the terms and > conditions either of that version or of any later version published by > the Free Software Foundation. If the Library does not specify a > license version number, you may choose any version ever published by > the Free Software Foundation. > > 14. If you wish to incorporate parts of the Library into other free > programs whose distribution conditions are incompatible with these, > write to the author to ask for permission. For software which is > copyrighted by the Free Software Foundation, write to the Free > Software Foundation; we sometimes make exceptions for this. Our > decision will be guided by the two goals of preserving the free status > of all derivatives of our free software and of promoting the sharing > and reuse of software generally. > > NO WARRANTY > > 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO > WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. > EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR > OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY > KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE > IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE > LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME > THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. > > 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN > WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY > AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU > FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR > CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE > LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING > RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A > FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF > SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH > DAMAGES. > > END OF TERMS AND CONDITIONS > > How to Apply These Terms to Your New Libraries > > If you develop a new library, and you want it to be of the greatest > possible use to the public, we recommend making it free software that > everyone can redistribute and change. You can do so by permitting > redistribution under these terms (or, alternatively, under the terms of the > ordinary General Public License). > > To apply these terms, attach the following notices to the library. It is > safest to attach them to the start of each source file to most effectively > convey the exclusion of warranty; and each file should have at least the > "copyright" line and a pointer to where the full notice is found. > > > Copyright (C) > > This library is free software; you can redistribute it and/or > modify it under the terms of the GNU Lesser General Public > License as published by the Free Software Foundation; either > version 2.1 of the License, or (at your option) any later version. > > This library is distributed in the hope that it will be useful, > but WITHOUT ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > Lesser General Public License for more details. > > You should have received a copy of the GNU Lesser General Public > License along with this library; if not, write to the Free Software > Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > > Also add information on how to contact you by electronic and paper mail. > > You should also get your employer (if you work as a programmer) or your > school, if any, to sign a "copyright disclaimer" for the library, if > necessary. Here is a sample; alter the names: > > Yoyodyne, Inc., hereby disclaims all copyright interest in the > library `Frob' (a library for tweaking knobs) written by James Random Hacker. > > , 1 April 1990 > Ty Coon, President of Vice > > That's all there is to it! > ------------------------ end of proposed license ------------------ > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From gjhanna at gmail.com Sun Mar 11 14:21:17 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Mon, 12 Mar 2007 09:21:17 +1300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hi Pavel, We are using RXTX under VMWare server in production, quite satisfactorily. We're using Red Hat Enterprise Server 4, and ... Whatever the "enterprise" VMWare product is. Regards, Greg H > Subject: [Rxtx] RXTX under VMWare server > To: rxtx at qbang.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. [ ... snip ... ] -- Pavel Parkhomenko -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070311/4cebb6f9/attachment-0084.html From gergg at cox.net Sun Mar 11 23:39:19 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 12 Mar 2007 00:39:19 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: <45F4E787.6050502@cox.net> Trent Jarvi wrote: > I can start going through the method interfaces later this week and giving > feedback. I would suggest that the JSR should not be too generic in > nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel > drivers that intend to look like EIA232 ports at the kernel driver level. > > some ideas: > > EIA232PortInterface > TermiosInterface > SerialPortInterface > > Something that differentiates this from thing like USB, I2C, ... which > should not have to deal with legacy serial claiming to be the comm api. I'm going to throw out a suggestion, which I am mostly serious about. What would happen if we took the appropriate bits of the J2ME connector API, and just used that as the new COMM API so that finally JSE and JME had a common foundation for these kinds of things? Gregg Wonderly From ra85551 at gmail.com Mon Mar 12 09:08:37 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Mon, 12 Mar 2007 18:08:37 +0300 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Should any application use the modem, HyperTerminal won't be able to talk to the modem. But it actually can send and receive AT comands, while my application cannot :-( > Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Thansk for the reference. I examined that example and found that there's no significant differences between my read/write implementation and that one, except that SimpleSnuV1 listens for serialEvent's, but not for sake of data retrieval, just for printing them out - I don't know why ;-) > Note that modems could care less what OS is on top. If you are trying to > match new lines to the OS and sending it to the mode for AT commands, > thats probably a mistake. I do send strings to serial port, not to OS, and do try to get answers back. If it is the mistake, what's the right way? > Also it would not hurt to print out the > individual bytes that you are sending to make sure they did not get > mangled along the path. Yeah, I am printing these bytes before doing write, but it means that I only see what I intend to write. How can I ensure that these bytes have gone out of the box and reached my modem? BTW, I found that my send/receive method is complex enough, so I've rewritten it. Please, see the following code and point any mistakes, because I don't know where can they remain yet. private static final int LARGE_TIMEOUT = 15000; private static final int SMALL_TIMEOUT = 500; ... private String sendATCommand(String command, String waitFor, boolean isRegex, boolean isAddCRLF) throws BeaconConnectException { byte[] buffer = new byte[512]; int offset; String result = ""; try { if (waitFor != null) { serialPort.enableReceiveTimeout(LARGE_TIMEOUT); } else { serialPort.enableReceiveTimeout(SMALL_TIMEOUT); } if (command != null) { OutputStream serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } offset = 0; InputStream serialInput = serialPort.getInputStream(); while (serialInput.available() != -1) { int bytesRead = serialInput.read(buffer, offset, buffer.length - offset); if (bytesRead == 0) { break; } offset += bytesRead; result = new String(buffer, 0, offset).trim(); if (waitFor != null) { System.out.println(result); if (isRegex && result.matches(waitFor) || result.contains(waitFor)) { break; } } } } catch (UnsupportedCommOperationException e) { throw new MyException("unsupported operation"); } catch (IOException e) { throw new MytException("serial I/O error"); } return result; } -- Pavel Parkhomenko From clayno at hotpop.com Thu Mar 15 02:47:34 2007 From: clayno at hotpop.com (Christopher Layno) Date: Thu, 15 Mar 2007 16:47:34 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi, we're using the latest release of rxtx (2.1-7r2) for our system that has two applications using the library. one application sends requests to the modem while the other simply checks the modem status. we deployed our system on a pentium machine with red hat linux 9.0 installed. now the problem arises when these two applications try to access the same modem at the same time. one of them will eventually have to throw the PortInUseException as shown below: 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException gnu.io.PortInUseException: root PID = 743 Program = java root PID = 743 Program = java root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) this was expected. what we didn't expect though was that if we repeat the scenario 5 times, always 5 times, the application would also throw a VM error: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4473CD21 Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so Current Java thread: at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) - locked <0x44cfd4c8> (a gnu.io.CommPortIdentifier) at ************ at ************ - locked <0x4476a468> (a **********) at ************ at ************ at ************ at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java :261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages( TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run( TCPTransport.java:701) at java.lang.Thread.run(Thread.java:534) note: i replaced some sensitive data with asterisks our team has looked everywhere on the internet, including your mail archives, for a solution to this problem but to no avail. i really hope you could help us out on this one. thanks in advance! best regards, chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070315/1936460a/attachment-0081.html From tjarvi at qbang.org Fri Mar 16 04:30:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 04:30:25 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: On Thu, 15 Mar 2007, Christopher Layno wrote: > hi, > > we're using the latest release of rxtx (2.1-7r2) for our system that has two > applications using the library. one application sends requests to the modem > while the other simply checks the modem status. we deployed our system on a > pentium machine with red hat linux 9.0 installed. > > now the problem arises when these two applications try to access the same > modem at the same time. one of them will eventually have to throw the > PortInUseException as shown below: > > 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException > gnu.io.PortInUseException: root PID = 743 Program = java root PID = > 743 Program = java root PID = 743 Program = ??? root PID = 743 Program > = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root > PID = 743 Program = ??? root PID = 743 Program = ??? > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > > this was expected. what we didn't expect though was that if we repeat the > scenario 5 times, always 5 times, the application would also throw a VM > error: > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x4473CD21 > Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 > Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so > > Current Java thread: > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) Hi Chris The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. The code is originally by Werner Almesberger. He gave us permission to use it in rxtx. You might look at what has changed since 1998 in his fuser application. Or you can just do like other OSs and do the following in fuserImp.c JNIEXPORT jstring JNICALL Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv *env, jobject obj, jstring arg) { return (*env)->NewStringUTF(env, "Unknown Application"); } It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. -- Trent Jarvi tjarvi at qang.org From Adrien.TOS at ingenico.com Fri Mar 16 05:11:12 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Fri, 16 Mar 2007 12:11:12 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903CBC312@frsnprexc1.usr.ingenico.loc> Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070316/972ab214/attachment-0080.html From joachim at buechse.de Fri Mar 16 05:13:24 2007 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 16 Mar 2007 12:13:24 +0100 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. From tjarvi at qbang.org Fri Mar 16 16:36:29 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 16:36:29 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Fri Mar 16 16:02:23 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 16 Mar 2007 18:02:23 -0400 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Not all platforms are Unix based. Also mixing native library usage and command-line calls is not an elegant solution, IMHO. One or the other, but not both. Andre On 16-Mar-07, at 07:13 , Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is > trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We >> only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From clayno at hotpop.com Sun Mar 18 22:17:28 2007 From: clayno at hotpop.com (Christopher Layno) Date: Mon, 19 Mar 2007 12:17:28 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi everyone, thank you so much for your replies. they were really helpful. anyway, before i sent the email, my team was already implementing a temporary solution by using joachim's suggestion. we invoked a lsof command from our java code although i share the same concern with trent and andre-john about portability issues. that's why i said it's just temporary. my superiors have yet to approve our bug fix. so my question now is this: is recompiling the rxtx source code the only way to solve this problem? because if it's the only solution, then i think my superiors would rather have a new release from the rxtx community itself that fixes this bug(?) rather than have my team recompile the source code. best regards, chris Trent Jarvi wrote: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. ... It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070318/237463b2/attachment-0077.html From tjarvi at qbang.org Mon Mar 19 16:20:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Mar 2007 16:20:52 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: Hi Chris I can compile a new version after the 21st if you do not feel comfortable doing so. Please send me an email reminder off-line then. On Mon, 19 Mar 2007, Christopher Layno wrote: > hi everyone, > > thank you so much for your replies. they were really helpful. > > anyway, before i sent the email, my team was already implementing a > temporary solution by using joachim's suggestion. > we invoked a lsof command from our java code although i share the same > concern with trent and andre-john about > portability issues. that's why i said it's just temporary. my superiors have > yet to approve our bug fix. > > so my question now is this: is recompiling the rxtx source code the only way > to solve this problem? because if it's the only > solution, then i think my superiors would rather have a new release from the > rxtx community itself that fixes this bug(?) > rather than have my team recompile the source code. > > best regards, > > chris > > Trent Jarvi wrote: > > Hi Joachim > > It would be nice to have that functionality but calling the program > introduces too many issues imho. Explaining to someone why rxtx invoked a > rogue lsof does not sound very interesting. > > On Fri, 16 Mar 2007, Joachim Buechse wrote: > > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: > > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. > > _______________________________________________ > Rxtx mailing list > Rxtx 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 Eric.Arseneau at sun.com Tue Mar 20 11:47:33 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Tue, 20 Mar 2007 10:47:33 -0700 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 Message-ID: <46001E35.9040608@sun.com> Anyone have any experience with RXTX working with JDK 6 on other platforms ? From mm at UDel.Edu Tue Mar 20 12:18:29 2007 From: mm at UDel.Edu (Mike Markowski) Date: Tue, 20 Mar 2007 14:18:29 -0400 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 In-Reply-To: <46001E35.9040608@sun.com> References: <46001E35.9040608@sun.com> Message-ID: <46002575.4000306@udel.edu> Eric Arseneau wrote: > Anyone have any experience with RXTX working with JDK 6 on other platforms ? I'm using 32 bit intel, gentoo linux, jdk6 with no problems. My applications only use a serial port, though, nothing on the parallel port. Mike From falko.guderian at gmx.de Wed Mar 21 08:17:35 2007 From: falko.guderian at gmx.de (Falko Guderian) Date: Wed, 21 Mar 2007 15:17:35 +0100 Subject: [Rxtx] RXTX binaries for SH4 Message-ID: <46013E7F.40102@gmx.de> Dear developers, I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no possiblities to compile the source code. Better, I'm not able to do this at the moment. Can you provide me with rxtxSerial.dll (SH4) in the rxtx-2.1-8-testing version? (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) The reason for the testing version is I need custom baud rates. Thanks for help. Kind regards, Falko Guderian From tjarvi at qbang.org Wed Mar 21 21:38:37 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Mar 2007 21:38:37 -0600 (MDT) Subject: [Rxtx] RXTX binaries for SH4 In-Reply-To: <46013E7F.40102@gmx.de> References: <46013E7F.40102@gmx.de> Message-ID: On Wed, 21 Mar 2007, Falko Guderian wrote: > Dear developers, > > I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no > possiblities to compile the source code. Better, I'm not able to do this > at the moment. Can you provide me with rxtxSerial.dll (SH4) in the > rxtx-2.1-8-testing version? > (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) > > The reason for the testing version is I need custom baud rates. > > Thanks for help. > Hi Falko WinCE binary format is not supported by gcc. That makes compiling limited to those familiar with the WinCE tools. I hope someone is able to provide them for you but it is not likely. WinCE has been compiled by others in the past but rxtx.org builds have never included WinCE. There is some information with the source concerning WinCE builds if you decide to do it. We can share your results too if you like. The source in the WinCE has never been updated for the custom baud rate. That would need changes from the main source I presume. If you look at the source, you will note that Michal Hobot created a mini fork in the source to handle wince but it has not been updated for 3 years. -- Trent Jarvi tjarvi at qbang.org From Adrien.TOS at ingenico.com Thu Mar 22 07:08:55 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Thu, 22 Mar 2007 14:08:55 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Hi everybody, Do you have any comments on this issue? Thanks! AT ________________________________ De : Adrien TOS Envoy? : vendredi 16 mars 2007 12:11 ? : 'rxtx at qbang.org' Cc : Adrien TOS Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070322/2306c538/attachment-0073.html From jeremy.reeve at zen.co.uk Mon Mar 19 07:36:04 2007 From: jeremy.reeve at zen.co.uk (Jeremy S. Reeve) Date: Mon, 19 Mar 2007 13:36:04 +0000 Subject: [Rxtx] rxtx failing to compile on Fedora Core 6 Message-ID: <1174311364.21865.6.camel@d9thc> When trying to compile latest source : rxtx-2.1-7r2 I get the following when running configure: ---------------- checking os.version 2.6.18-1.2200.fc5smp WARNING: configure is having a hard time determining which directory contains the file jni_md.h. Edit Makefile and fix the variable JAVANATINC to point to the correct directory. The following options are available: /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/ /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/linux/ If there are more than one option available the first was selected. WARNING: Kernel include files do not match the current kernel configure: creating ./config.status ------------------------ which seems OK checking the resultant Makefile but when attempting to build with gmake install I get the following output : ---------------------- 34 problems (34 warnings)/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/javah -classpath .:/home/jsr/rxtxsrc/rxtx-2.1-7r2:/home/jsr/rxtxsrc/rxtx-2.1-7r2/src:/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/ext/RXTXcomm.jar -d i686-pc-linux-gnu -jni `(for i in CommDriver CommPortEnumerator CommPortIdentifier CommPort CommPortOwnershipListener Configure I2C I2CPortEvent I2CPortEventListener I2CPort LPRPort NoSuchPortException ParallelPortEvent ParallelPortEventListener ParallelPort PortInUseException Raw RawPortEvent RawPortEventListener RawPort RS485 RS485PortEvent RS485PortEventListener RS485Port RXTXCommDriver RXTXPort RXTXVersion SerialPortEvent SerialPortEventListener SerialPort UnsupportedCommOperationException UnSupportedLoggerException Zystem;do \ if grep > /dev/null native.* \( /home/jsr/rxtxsrc/rxtx-2.1-7r2/./src/$i.java; then \ echo gnu.io.$i; \ fi; \ done)` i686-pc-linux-gnu/gnu_io_CommPortIdentifier.h: No such file or directory make: *** [/home/jsr/rxtxsrc/rxtx-2.1-7r2/gnu/io/CommDriver.class] Error 1 ------------------------ Any ideas or pointers? Regards, Jeremy From tjarvi at qbang.org Sat Mar 24 08:12:54 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 Mar 2007 08:12:54 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > From Adrien.TOS at ingenico.com Sat Mar 24 11:53:22 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Sat, 24 Mar 2007 18:53:22 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> I do not have the threshold setting enabled, I have explicitely disabled it with: port_.disableReceiveThreshold(); I have also run the same tests with the threshold setting enabled, but they also fail in the same way as described below. So it seems there is a problem with timeout handling on Win32? ________________________________ From: rxtx-bounces at qbang.org on behalf of Trent Jarvi Sent: Sat 3/24/2007 3:12 PM To: RXTX Developers and Users Subject: Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 8312 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20070324/f9e39c9b/attachment-0071.bin From greg.johnson at manchester.ac.uk Sun Mar 25 13:41:36 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Sun, 25 Mar 2007 21:41:36 +0200 Subject: [Rxtx] Mac intel weirdness Message-ID: Hi folks, I'm trying to get rxtx to work on my macbook pro with a USB-serial dongle on it. I am using the 2.1-8 code from the CVS (though it seems to report itself as 2.1-7: makes it difficult to prove to oneself that the changes have 'taken'! - line 4210 in SerialImp.c, line 40 in RXTXVersion.java) I am trying the 2.1-8 because of horrible lock problems in 2.1-7. However, the serialport closure code seems to be broken - it won't close because it believes the (previously opened!) port doesn't exist. Here is what I'm trying: 0. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "false" 1. Open a port Serialport serialport = (SerialPort) commportidentifier.open ("test",100); 2. Talk to a device ... 3. Close port serialport.close(); 4. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "true" - why is this? 5. Try to reopen port Serialport serialport2 = (SerialPort) commportidentifier.open("test", 100); throws PortInUseException. I've dug around a bit in the source, and it seems the SerialPort.close () should call the CommPortIdentifier.internalClosePort() (line 67 of CommPort.java). However, I crash out with the NoSuchPortException when getPortIdentifier is called. Which seems quite weird to me, seeing as it is called on this - which was create just beforehand. Does anyone know how to fix this? Cheers, greg From knute at frazmtn.com Sat Mar 24 10:32:38 2007 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 24 Mar 2007 09:32:38 -0700 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc>, Message-ID: <4604F036.17833.135298@knute.frazmtn.com> > >The behavior of timeout depends upon the setting of the threshold. Do you >have the threshold setting? > This is the same bug I reported last fall. There was a fellow that sent me an email asking if it had been fixed. I told him I didn't think so. He got somebody to write a fix for him but I have not been able to contact him again for the actual changes. The inaccurate timeout and the failure of blocking when no timeouts are set is a serious bug in my humble opinion and renders the software unusable for my applications. I'd really like to have an alternative to the Sun comm api but there just isn't one that I know of. -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Mar 26 16:17:00 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 26 Mar 2007 16:17:00 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> Message-ID: >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. From ra85551 at gmail.com Tue Mar 27 10:18:36 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Tue, 27 Mar 2007 20:18:36 +0400 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Ultimately I found a solution. At first, that wasn't actually the VMWare + WinXP + RXTX issue, that was WinXP + RXTX issue. But on pure XP it sometimes workes, sometimes not, while under VMWare I had never seen my snippet working at all. SimpleSnuV1.java would not help me, because there is only one line I missed, and SimpleSnuV1.java also doesn't contain it! It is as follows: serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_OUT | SerialPort.FLOWCONTROL_RTSCTS_IN); Thank you for your attention. -- Pavel Parkhomenko From griff at op.pl Wed Mar 28 01:28:19 2007 From: griff at op.pl (griff@op.pl) Date: Wed, 28 Mar 2007 09:28:19 +0200 Subject: [Rxtx] No blocking read on Windows. Message-ID: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/5d07d571/attachment-0068.html -------------- next part -------------- Hi, I have problem that InputStram.read() (SerialPort)?returns -1 instead blocking and waiting for data. I found that this problem was ?known in 2005 : ? >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > >> Hi Trent >> >> Thanks for the fast response. >> Here's a Q&D test program for the blocking read on windows that just >> attempts to read one byte, and prints the resulting byte. On my system it >> returns -1, where I expect that it keeps waiting for data. >> >This isn't happening on Linux so the bug is in src/termios.c.? I'll have >something this weekend to fix that. I'm using RXTX 2.1.7r2 and the problem still is here. Im using Windows XP and java 1.5 disableReciveTimeout() and disableReciveTreshhold() dont help. ? best regards ? Piotr Zielniok From Adrien.TOS at ingenico.com Wed Mar 28 01:40:46 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Wed, 28 Mar 2007 09:40:46 +0200 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903E88880@frsnprexc1.usr.ingenico.loc> Looking at the code, it seems there is no support for infinite timeout? And maybe the count++ < 20 condition is breaking out of the loop too early? The only condition to break out of the loop should either be the timeout has expired or the number of requested bytes has been received. -----Message d'origine----- De : rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] De la part de Trent Jarvi Envoy? : mardi 27 mars 2007 00:17 ? : RXTX Developers and Users Objet : Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From j.kenneth.gentle at acm.org Wed Mar 28 06:44:15 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 28 Mar 2007 08:44:15 -0400 Subject: [Rxtx] No blocking read on Windows. In-Reply-To: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> References: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> Message-ID: <200703281844.l2SIiITW028614@qbang.org> Just another "ME TOO!" - I'm seeing this problem on Windows XP, jre for windows XP/Embedded. I cranked receiveTimeout up to Integer.MAX_INT, but it doesn't seem to wait that long At 03:28 2007-03-28, you wrote: >Hi, >I have problem that InputStram.read() (SerialPort) returns -1 >instead blocking and waiting for data. I found that this problem >was known in 2005 : > > >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > > > >> Hi Trent > >> > >> Thanks for the fast response. > >> Here's a Q&D test program for the blocking read on windows that just > >> attempts to read one byte, and prints the resulting byte. On my system it > >> returns -1, where I expect that it keeps waiting for data. > >> > > >This isn't happening on Linux so the bug is in src/termios.c. I'll have > >something this weekend to fix that. > >I'm using RXTX 2.1.7r2 and the problem still is here. >Im using Windows XP and java 1.5 >disableReciveTimeout() and disableReciveTreshhold() dont help. > >best regards > >Piotr Zielniok > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From greg.johnson at manchester.ac.uk Wed Mar 28 14:43:29 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Wed, 28 Mar 2007 22:43:29 +0200 Subject: [Rxtx] Cannot close and reopen serial port Message-ID: <377F9765-7A9D-4CE9-9176-FFB63A2594F0@manchester.ac.uk> Dear all, It appears I cannot close a port properly: SerialPort serialport = portid.open("myprog",100); // do some stuff, all works fine serialport.close(); // all seems fine but... SerialPort sp2 = portid.open("myprog",100); throws PortInUseException. And when I dig into the rxtx code, I find in CommPort.java, in close(): CommPortIdentifier cp = CommPortIdentifier.getPortIdentifier(this); (line 64 or there abouts) but this throws a NoSuchPortException which is caught but ignored (line 74ish). Can anyone suggest how this could happen: a port that was valid, opened, and used, throws a NSPE when it comes to closing it? I'm pulling my (remaining) hair out over this one! Cheers, greg PS And thanks for RXTX - it's great to have! PPS (21.-7. winxp/osx both, java 1.5) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/c28852fc/attachment-0067.html From rxtx at vrijheidslaan.net Fri Mar 30 16:52:50 2007 From: rxtx at vrijheidslaan.net (Rob) Date: Fri, 30 Mar 2007 22:52:50 -0000 Subject: [Rxtx] Cvs Question Message-ID: <61896.80.126.150.87.1175295162.squirrel@webmail.provalue.nl> Hi There, Im trying to get the latest version to work on mac osx. Problem is that i can't checkout version 2.1.8. Probably my fault but can some one please give me the alternative commands for: [user at myhost]$ export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot [user at myhost]$ cvs login Thanx, Rob From ra85551 at gmail.com Thu Mar 1 03:47:06 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Thu, 1 Mar 2007 13:47:06 +0300 Subject: [Rxtx] enableReceiveTimeout() issue Message-ID: Hello, world! I found a limitation of 16300 ms for CommPort's enableReceiveTimeout() method, while in original javax.comm docs there are no any references to that. Is that a bug or feature? I actually need longer timeouts sometimees. -- Pavel Parkhomenko From lyon at docjava.com Thu Mar 1 07:54:17 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 01 Mar 2007 09:54:17 -0500 Subject: [Rxtx] parametric singleton design pattern In-Reply-To: References: <22d55aea0702081207q5e7f6785l352d498d6f5f9fb1@mail.gmail.com> <22d55aea0702100034o3bcf42f3j1d1a6257029a67b0@mail.gmail.com> Message-ID: Hi All, I have been thinking about the use of a design pattern to cache resources that are consumed by processes. Toward that end, I have arrived at a parametric singleton design pattern, which I mentioned on this list some time ago. The idea has been published at: http://www.jot.fm/issues/issue_2007_03/column2 I can't help but think that there should be an API available for dealing with the tracking of serial port usage. Perhaps it is a kind of resource manager called the: SerialPortManager basic prototypes already exist in this vain. See, for example: http://www.ce.rit.edu/research/projects/2005_fall/rt_poolsystem/doc/PoolMon/SerialPortManager.html http://www.eventhelix.com/RealtimeMantra/PatternCatalog/serial_port_design_pattern.htm And others shown by a google search on "SerialPortManager" Cheers! - Doug From Eric.Arseneau at sun.com Thu Mar 1 10:15:03 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:15:03 -0800 Subject: [Rxtx] Any known Java 6 issues with RXTX 2.1-7r2 ? Message-ID: <45E70A17.1060206@sun.com> I just did a test on a recent build of Solaris 11 x86 and it seems that I can connect to my serial device fine when Java 5 is the default, but when Java 6 is the default, no go. Any information ? From Eric.Arseneau at sun.com Thu Mar 1 10:19:58 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:19:58 -0800 Subject: [Rxtx] Mac OS X and missing data Message-ID: <45E70B3E.7040908@sun.com> We have a device which is USB based but presents itself as a serial port to a machine. On my MacBook Pro I can get excellent throughput if I get my device to send data as quickly as possible. On the desktop side, if I do an type of disk IO to log the data I get, I end up with some missing data at some point. I hooked up a USB analyzer and did confirm that all the data is sent as expected to the desktop from the device. I found a work around for this, buffer the data in memory and only write the data out when I've received it all. However, when the same code and same device is attempted on a co-workers MacBook Pro (same hardware specs), I get errors and must slow down dramatically the device side's sending of data. Any ideas/recommendations on what I can do to get rid of this error ? From what I can tell, it seems that RXTX is not able to wake up to the interrupts coming in indicating data is ready, quickly enough, is there anything I can do ? From chinkaiw at hotmail.com Fri Mar 2 00:57:43 2007 From: chinkaiw at hotmail.com (Wang Chinkai) Date: Fri, 02 Mar 2007 07:57:43 +0000 Subject: [Rxtx] dynamic detect rs232 port Message-ID: Hi all I have a question about detecting rs232 port dynamicly. I have to aceess some port and detect rs232 port at the same time. Some usb device simulates rs232 port , and I can not know what the port name it gets until it connects,so I have to detect it dynamic,but I have to access another rs232 device at the same time. I found a problem. If I use CommPortIdentifier.getPortIdentifiers() to get new port list , and the other rs232 access function will not close port correctly. So , How can I solve it . Thanks. _________________________________________________________________ ?? 2GB ???? Windows Live Mail ????????????? http://ideas.live.com/programpage.aspx?versionid=5d21c51a-b161-4314-9b0e-4911fb2b2e6d From eu259473 at tele2.it Fri Mar 2 06:16:40 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 02 Mar 2007 14:16:40 +0100 Subject: [Rxtx] rxtx on HP tru 64 unix Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070302/706c7a70/attachment-0095.html From tjarvi at qbang.org Fri Mar 2 08:39:33 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 08:39:33 -0700 (MST) Subject: [Rxtx] rxtx on HP tru 64 unix In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, "Giuseppe Marchese" wrote: > Hi > > I try to install rxtx on hp tru 64 but make fails, > There are somebody that do the same and work. > > > Sorry for may english! > > Hi Giuseppe Could you provide a log of the failure? script ./configure make # use gnu make exit The information will be in the typescript created. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 2 19:56:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 19:56:52 -0700 (MST) Subject: [Rxtx] dynamic detect rs232 port In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, Wang Chinkai wrote: > Hi all > > I have a question about detecting rs232 port dynamicly. > > I have to aceess some port and detect rs232 port at the same time. > Some usb device simulates rs232 port , and I can not know > what the port name it gets until it connects,so I have to detect it > dynamic,but I have to access > another rs232 device at the same time. > > I found a problem. Hi Wang This is a known problem. The code is braindead there. In fact there needs to be events even in a rudamentary way when you add a usb dongle. I'm burried in tasks not far from rxtx but not in rxtx. I can't get to the problem but we would accept patches if you dig into it. [I'm getting to the license question earlier too; I don't have another 10%] -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Fri Mar 2 23:19:01 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 01:19:01 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Hi, Under ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable USB -> serial converter(using virtual com port drivers), with using example code pretty much straight out of http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port opens fine, enumerations all work, etc. My application calls for a large amount of data to be transferred in a short amount of time at 2,000,000 baud. My hardware sends approximately 15,232 bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL converter work fine, and the application works using C++. In C++, I do a hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); to open the port, and a boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); to read the port. The variable buffer fills with the 15238 bytes, and returns. If I do a resultz = is.read(cbuf,0,15238); in java with RXTX where is = new BufferedReader(new InputStreamReader(port.getInputStream())); and where resultz is an int, and cbuf is a char [] cbuf, resultz gets EXACTLY 3968 bytes the first time called. If I call it multiple times, I get roughly 11k total(less than what is sent), never more than the 3968 bytes per is.read() call. My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 bytes. I've played with inputbuffersize, receive threshold, receivetimeout, and so on. The FTDI virtual com port drivers that I'm using are rock solid, and have had zero problems with them using a variety of applications, some of my own, some professionally written, etc. No flow control is used anyplace, no RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. No exceptions are being thrown. What am I doing wrong, and what I can adjust to receive the full 15k bytes in one single read? Thanks! Keith From Eric.Arseneau at sun.com Fri Mar 2 23:32:07 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Fri, 02 Mar 2007 22:32:07 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <45E91667.20501@sun.com> This is the same type of thing that is happening to me on Mac OS X and does not seem to behave the same on different machines. I posted a day or two ago on this with subject "Mac OS X and missing data". Would love to hear if there is a solution to this :) From tjarvi at qbang.org Sat Mar 3 10:54:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 10:54:17 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > Hi, > > Under > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable > USB -> serial converter(using virtual com port drivers), with using example > code pretty much straight out of > http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port > opens fine, enumerations all work, etc. > > My application calls for a large amount of data to be transferred in a short > amount of time at 2,000,000 baud. My hardware sends approximately 15,232 > bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL > converter work fine, and the application works using C++. > > In C++, I do a > > hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, > OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); > > to open the port, and a > > boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); > > to read the port. > > The variable buffer fills with the 15238 bytes, and returns. > > If I do a > > resultz = is.read(cbuf,0,15238); in java with RXTX > > where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > > and where resultz is an int, and cbuf is a char [] cbuf, resultz gets > EXACTLY 3968 bytes the first time called. If I call it multiple times, I get > roughly 11k total(less than what is sent), never more than the 3968 bytes > per is.read() call. > > My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 > bytes. > > I've played with inputbuffersize, receive threshold, receivetimeout, and so > on. The FTDI virtual com port drivers that I'm using are rock solid, and > have had zero problems with them using a variety of applications, some of my > own, some professionally written, etc. No flow control is used anyplace, no > RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. > > No exceptions are being thrown. > > What am I doing wrong, and what I can adjust to receive the full 15k bytes > in one single read? > > Thanks! > Hi Keith I would expect a 20 meg application is going to have different behavior with the OS than a smaller application with respect to the kernel memory managment, schedualing, ... Something subtle could be causing problems. With respect to the recieve timeout and threshold, if you set the timeout to zero and the threshold to the size of data you expect, read should not return until it get that data. You may try with a stand alone application that tests just that with the C/C++ API. If the read is returning with less data when tested for short reads, you have found a bug in the device driver more than likely. The USB dongle vendor would probably be interested in knowing about this. As mentioned, these devices are getting very good; almost bug free. I suspect you found a bug though if you did use the threshold and timeout properly. The missing data is typical when not using flow control. When the OS buffering fills, the hardware will start dropping bytes. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:38:52 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:38:52 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> update: I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now instead of 3968. This makes sense. 128 bytes of overhead + 3968 bytes of data = 4096 transfer size 32 bytes of overhead + 992 bytes of data = 1024 transfer size. 1/4 the data = 1/4 the overhead. I rearranged my reading like so: resultz = is.read(cbuf,0,3968); resultz = is.read(cbuf,3968,3968); resultz = is.read(cbuf,7936,3968); while (!(is.ready())); // wait for ready resultz = is.read(cbuf,11904,3334); and this grabs 15,238 bytes total. BUT, I still have the quandry of the screwed up multi-bytes. I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. Approx 8% of the data. The bad bytes always seem to take the flavor of 0x2018, 0x2019, x2022, x2030, x201d. Are these maybe errors and I don't know what they enumerate to? I still can't believe some other layer isn't handling putting those bytes together all in one stream for me. Thanks Keith ----- Original Message ----- From: "Keith" To: "Bob Jacobsen" ; "RXTX Developers and Users" Sent: Saturday, March 03, 2007 11:26 AM Subject: Re: [Rxtx] is.read() only returning 3968 bytes > Bob, > > > Interesting numerical coincidence is that (max USB transfer) - (what > > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > > needed to transfer that much data. > > I was thinking along the same lines. I don't know USB well, but I do know > that those numbers were close enough to warrant investigating the > relationship between them. > > > I think what you're seeing is the internal buffering of the USB data > > stream. You'll need some form of higher-level buffering to smooth > > that out. > > Shouldn't the InputStreamReader() and BufferedReader() provide this type of > buffering? Isn't that the idea behind those? > > > All hypotheses need to be tested. In this case, a test would be to > > check for missing data. If this idea is right, you'll get _all_ the > > data, but you won't be missing characters. > > I did start looking at the data. -- I'm getting weird results. > > I tried this: > > loopzz = 0; > > for (looptwo = 0; looptwo < 100000; looptwo++) { > while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > > }} > > So I'm reading one character at a time. The good news is that loopzz is > exactly 15238 at the end of the routine, which is perfectly correct. I > picked looptwo value out of thin air. > > The weird results come in terms of the values, the data isn't correct at > least in one case. Look here: > > 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > > This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). > But the 0x89 was replaced by 0x2030. Why the heck would the returned value > be 0x2030?? Why is the returned byte completely out of range? Why the > multibyte return? > > From InputStream in the API: > > read > public abstract int read() > throws IOExceptionReads the next byte of data from the > input stream. The value byte is returned as an int in the range 0 to 255. If > no byte is available because the end of the stream has been reached, the > value -1 is returned. This method blocks until input data is available, the > end of the stream is detected, or an exception is thrown. > Value should be 0-255. > > > In my application time is really critical, reading 1 byte at a time is > probably not going to work. > > Thanks Eric & Bob for looking at this. > > Keith > From tjarvi at qbang.org Sat Mar 3 12:52:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 12:52:27 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > update: > > I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now > instead of 3968. > > This makes sense. > > 128 bytes of overhead + 3968 bytes of data = 4096 transfer size > 32 bytes of overhead + 992 bytes of data = 1024 transfer size. > > 1/4 the data = 1/4 the overhead. > > I rearranged my reading like so: > > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. > Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? > > I still can't believe some other layer isn't handling putting those bytes > together all in one stream for me. > The layer for this in Serial land is flow control. Software and hardware flow control prevent the overruns you observe. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:54:41 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:54:41 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <001a01c75dcd$c8802a70$6600a8c0@jbh757ktruws7g> Trent, Thanks for taking the time to reply. > I would expect a 20 meg application is going to have different behavior > with the OS than a smaller application with respect to the kernel memory > managment, schedualing, ... Something subtle could be causing problems. Well, at least I know the VCP drivers, the OS, etc can handle 2mbps reliably. Without hiccuping or dropping bytes. The C++ code works reliably without flow control. > The missing data is typical when not using flow control. When the OS > buffering fills, the hardware will start dropping bytes. I'm actually not getting MISSING data, I'm getting CORRUPTED data. If you look at my most recent post, I'm getting these bad bytes in place of the correct values: 0x2018, 0x2019, x2022, x2030, x201d. Why would is.read() return values not in the range of 0-255 ? Thanks. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 08:59:14 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 07:59:14 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: At 1:19 AM -0500 3/3/07, Keith wrote: >If I do a > >resultz = is.read(cbuf,0,15238); in java with RXTX > >where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > >and where resultz is an int, and cbuf is a char [] cbuf, resultz gets >EXACTLY 3968 bytes the first time called. If I call it multiple times, I get >roughly 11k total(less than what is sent), never more than the 3968 bytes >per is.read() call. > >My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 >bytes. Interesting numerical coincidence is that (max USB transfer) - (what you get) = 4096-3968 = 128 bytes is (almost) the size of the headers needed to transfer that much data. I think what you're seeing is the internal buffering of the USB data stream. You'll need some form of higher-level buffering to smooth that out. All hypotheses need to be tested. In this case, a test would be to check for missing data. If this idea is right, you'll get _all_ the data, but you won't be missing characters. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 09:26:14 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 11:26:14 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Bob, > Interesting numerical coincidence is that (max USB transfer) - (what > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > needed to transfer that much data. I was thinking along the same lines. I don't know USB well, but I do know that those numbers were close enough to warrant investigating the relationship between them. > I think what you're seeing is the internal buffering of the USB data > stream. You'll need some form of higher-level buffering to smooth > that out. Shouldn't the InputStreamReader() and BufferedReader() provide this type of buffering? Isn't that the idea behind those? > All hypotheses need to be tested. In this case, a test would be to > check for missing data. If this idea is right, you'll get _all_ the > data, but you won't be missing characters. I did start looking at the data. -- I'm getting weird results. I tried this: loopzz = 0; for (looptwo = 0; looptwo < 100000; looptwo++) { while (is.ready()) { cbuf[loopzz] = (char) is.read(); loopzz++; }} So I'm reading one character at a time. The good news is that loopzz is exactly 15238 at the end of the routine, which is perfectly correct. I picked looptwo value out of thin air. The weird results come in terms of the values, the data isn't correct at least in one case. Look here: 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). But the 0x89 was replaced by 0x2030. Why the heck would the returned value be 0x2030?? Why is the returned byte completely out of range? Why the multibyte return? >From InputStream in the API: read public abstract int read() throws IOExceptionReads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown. Value should be 0-255. In my application time is really critical, reading 1 byte at a time is probably not going to work. Thanks Eric & Bob for looking at this. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 14:44:50 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 13:44:50 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: Java's "char" type is Unicode. I think what you're seeing is a bug in the byte -> Unicode translation. 0x2018, 0x2019 are the curly open and close quotes. There used to be (and might still be) bugs in the conversion of these in a couple of libc versions. Some of the ASCII -> ISO and ISO -> ASCII routines were a little over-ambitious with respect to handling the open and close quotes, and tried to convert them to the "curly" form inappropriately. Try _not_ casting it to char. Bob At 11:26 AM -0500 3/3/07, Keith wrote: >Bob, > >> Interesting numerical coincidence is that (max USB transfer) - (what >> you get) = 4096-3968 = 128 bytes is (almost) the size of the headers >> needed to transfer that much data. > >I was thinking along the same lines. I don't know USB well, but I do know >that those numbers were close enough to warrant investigating the >relationship between them. > >> I think what you're seeing is the internal buffering of the USB data >> stream. You'll need some form of higher-level buffering to smooth >> that out. > >Shouldn't the InputStreamReader() and BufferedReader() provide this type of >buffering? Isn't that the idea behind those? > >> All hypotheses need to be tested. In this case, a test would be to >> check for missing data. If this idea is right, you'll get _all_ the >> data, but you won't be missing characters. > >I did start looking at the data. -- I'm getting weird results. > >I tried this: > >loopzz = 0; > >for (looptwo = 0; looptwo < 100000; looptwo++) { >while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > >}} > >So I'm reading one character at a time. The good news is that loopzz is >exactly 15238 at the end of the routine, which is perfectly correct. I >picked looptwo value out of thin air. > >The weird results come in terms of the values, the data isn't correct at >least in one case. Look here: > >0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > >This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). >But the 0x89 was replaced by 0x2030. Why the heck would the returned value >be 0x2030?? Why is the returned byte completely out of range? Why the >multibyte return? > >>From InputStream in the API: > >read >public abstract int read() > throws IOExceptionReads the next byte of data from the >input stream. The value byte is returned as an int in the range 0 to 255. If >no byte is available because the end of the stream has been reached, the >value -1 is returned. This method blocks until input data is available, the >end of the stream is detected, or an exception is thrown. >Value should be 0-255. > > >In my application time is really critical, reading 1 byte at a time is >probably not going to work. > >Thanks Eric & Bob for looking at this. > >Keith > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 15:10:11 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 17:10:11 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Bob said ..... > Java's "char" type is Unicode. I think what you're seeing is a bug > in the byte -> Unicode translation. Bob -- I think you hit the nail on the head. I was just coming to the same realization here. I knew that something funny was going on because the same bytes always got "corrupted." I'm pretty sure its in the InputStreamReader() functionality where the conversion junk is happening. Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. I don't know if simply changing the cast is going to work. Since the conversion is happening upstream (pun intended), I don't think my cast is doing this. Also I think the compiler forced me to use the cast. I'm still playing around, and I'll report back once I nail it down. Thanks!! Keith From tjarvi at qbang.org Sat Mar 3 15:59:46 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 15:59:46 -0700 (MST) Subject: [Rxtx] Win64 rxtx Testers? Message-ID: I have compiled win64 binaries of rxtx. Are there any users interested in testing them? If so, I'll look into putting them on the web site. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Mar 3 15:35:06 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 14:35:06 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: Because of this and similar problems, JMRI does all it's serial IO using +only+ byte values. It's a but of a pain, as Java wants to go to char and int types a little too aggressively, but it does solve the "uncontrolled conversions" problems. Bob At 5:10 PM -0500 3/3/07, Keith wrote: >Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > >Bob -- I think you hit the nail on the head. > >I was just coming to the same realization here. I knew that something funny >was going on because the same bytes always got "corrupted." > >I'm pretty sure its in the InputStreamReader() functionality where the >conversion junk is happening. > >Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > >I don't know if simply changing the cast is going to work. Since the >conversion is happening upstream (pun intended), I don't think my cast is >doing this. Also I think the compiler forced me to use the cast. -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mark at mdsh.com Sun Mar 4 11:01:33 2007 From: mark at mdsh.com (Mark Himsley) Date: Sun, 04 Mar 2007 18:01:33 +0000 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: <5C01AC72C200388815C04982@bedroom.mdsh.local> On 03 March 2007 14:38 -0500 Keith wrote: > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT > consistent. Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? It looks like you need to use DataInputStream and DataOutputStream. -- Mark Himsley From tjarvi at qbang.org Sun Mar 4 11:35:08 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 11:35:08 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" > > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > > * Line #21 - Not sure if you need a (TM) mark for > the term "Sun" > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > OK. I'm going through this today. Some groups ask if rxtx could be under their license also. I think this is a good example of why I resist multiple licenses and focus on why the current license may not be usable by them. The RXTX project is a convergence of hobby and commercial interests. I happen to do both right now. The problem with licensing is we have to stay on top of them as they change. Clearly, adding more licenses will not make this easier. I'm acting as the hobby person today. RXTX always favors the hobby people. But as we move forward, I'm going to need to bring this to lawyers at work and explain to them what is going on. Others here may have to do this also. I don't anticipate problems or unexpected changes. The goal is a consistant, comprehendable and usable license as close to what we have now as possible. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 14:52:10 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 14:52:10 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (1/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: I'm breaking this into two parts. I expect the second part will need more attention. Comments first, then the changed material below. On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > Thanks > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. OK. RXTX for consitent use. java should not be capitalized because it does not only mean Sun [TM] Java [TM]. An example of this not meaning Java is when people use RXTX with GCJ. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". There are not any contributors that are in all of RXTX yet but I did update the comment to try to reflect the current situation without making it a nightmare to maintain. I looked to see how the Linux kernel does it as a reference point. > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" The URL can be problematic. I have done so below with a time reference. GNU does not provide version information in their URLS. I picture this being a problem when the version 3 comes out. > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > This will be corrected when the copy is updated to the version linked below. ---------------- begin proposed material involved -------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. ----------------- end proposed material involved -------------------- I'll be looking at the linking issue again next. That should be all that remains other than including the 2.1 version. Let me know if you have problems with anything here. I do not want to dilute the material I post next with these housekeeping tasks. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 16:08:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 16:08:36 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: For those that are wondering what is going on here, this next bit is the meat of the changes. We agreed a long time ago to put this disclaimer in. We did a so so job. It was in rxtx 2.0, not well written, ... So some groups using rxtx that would like to ship rxtx so users don't need to download, install, go to the mail-list to find why it failed, ... Then their legal teams tell them section 5 paragraph 2 is a show stopper. That was never the intent. Now going through what remains... > and might need a (TM) suffix to make Sun happy. Added disclaimer at the ended 'all trademarks belong...' > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. OK. As you can see I was trying to adjust GNU text there for the LGPL. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. used dynamically linked terminology. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". I tried to address this more upfront with an intent statement. Let me know if you have problems with it. I also tried to make it a little more clear what was derived from the GNU solution by moving the link location closer to GNU's suggestion. > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > Thats the intent. Here is the combined fixes. Note that only the material in /*-- --*/ is being touched. The new GPL license is there but unmodified. ------------------------ begin proposed new license ------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. | | An executable that contains no derivative of any portion of RXTX, but | is designed to work with RXTX by being dynamically linked with it, | is considered a "work that uses the Library" subject to the terms and | conditions of the GNU Lesser General Public License. | | The following has been added to the RXTX License to remove | any confusion about linking to RXTX. We want to allow in part what | section 5, paragraph 2 of the LGPL does not permit in the special | case of linking over a controlled interface. The intent is to add a | Java Specification Request or standards body defined interface in the | future as another exception but one is not currently available. | | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface | | As a special exception, the copyright holders of RXTX give you | permission to link RXTX with independent modules that communicate with | RXTX solely through the Sun Microsytems CommAPI interface version 2, | regardless of the license terms of these independent modules, and to copy | and distribute the resulting combined work under terms of your choice, | provided that every copy of the combined work is accompanied by a complete | copy of the source code of RXTX (the version of RXTX used to produce the | combined work), being distributed under the terms of the GNU Lesser General | Public License plus this exception. An independent module is a | module which is not derived from or based on RXTX. | | Note that people who make modified versions of RXTX are not obligated | to grant this special exception for their modified versions; it is | their choice whether to do so. The GNU Lesser General Public License | gives permission to release a modified version without this exception; this | exception also makes it possible to release a modified version which | carries forward this exception. | | You should have received a copy of the GNU Lesser General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA | All trademarks belong to their respective owners. --------------------------------------------------------------------------*/ The original GNU Lesser General Public License Follows. GNU LESSER GENERAL PUBLIC LICENSE Version 2.1, February 1999 Copyright (C) 1991, 1999 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. [This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence the version number 2.1.] Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This license, the Lesser General Public License, applies to some specially designated software packages--typically libraries--of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below. When we speak of free software, we are referring to freedom of use, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish); that you receive source code or can get it if you want it; that you can change the software and use pieces of it in new free programs; and that you are informed that you can do these things. To protect your rights, we need to make restrictions that forbid distributors to deny you these rights or to ask you to surrender these rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library or if you modify it. For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights. We protect your rights with a two-step method: (1) we copyright the library, and (2) we offer you this license, which gives you legal permission to copy, distribute and/or modify the library. To protect each distributor, we want to make it very clear that there is no warranty for the free library. Also, if the library is modified by someone else and passed on, the recipients should know that what they have is not the original version, so that the original author's reputation will not be affected by problems that might be introduced by others. Finally, software patents pose a constant threat to the existence of any free program. We wish to make sure that a company cannot effectively restrict the users of a free program by obtaining a restrictive license from a patent holder. Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license. Most GNU software, including some libraries, is covered by the ordinary GNU General Public License. This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs. When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library. We call this license the "Lesser" General Public License because it does Less to protect the user's freedom than the ordinary General Public License. It also provides other free software developers Less of an advantage over competing non-free programs. These disadvantages are the reason we use the ordinary General Public License for many libraries. However, the Lesser license provides advantages in certain special circumstances. For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License. In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software. For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU operating system, as well as its variant, the GNU/Linux operating system. Although the Lesser General Public License is Less protective of the users' freedom, it does ensure that the user of a program that is linked with the Library has the freedom and the wherewithal to run that program using a modified version of the Library. The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, whereas the latter must be combined with the library in order to run. GNU LESSER GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License Agreement applies to any software library or other program which contains a notice placed by the copyright holder or other authorized party saying it may be distributed under the terms of this Lesser General Public License (also called "this License"). Each licensee is addressed as "you". A "library" means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables. The "Library", below, refers to any such software library or work which has been distributed under these terms. A "work based on the Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term "modification".) "Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library. Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does. 1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) The modified work must itself be a software library. b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change. c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License. d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful. (For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library. In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. 4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange. If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code. 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables. When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law. If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.) Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself. 6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications. You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things: a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.) b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. c) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution. d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place. e) Verify that the user has already received a copy of these materials or that you have already sent this user a copy. For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute. 7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things: a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above. b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work. 8. You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 9. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Library (or any work based on the Library), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Library or works based on it. 10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties with this License. 11. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply, and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 12. If the distribution and/or use of the Library is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Library under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 13. The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation. 14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Libraries If you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the ordinary General Public License). To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Also add information on how to contact you by electronic and paper mail. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the library, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the library `Frob' (a library for tweaking knobs) written by James Random Hacker. , 1 April 1990 Ty Coon, President of Vice That's all there is to it! ------------------------ end of proposed license ------------------ -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sun Mar 4 16:26:04 2007 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 04 Mar 2007 17:26:04 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <45EB558C.3010609@cox.net> Bob Jacobsen wrote: > Because of this and similar problems, JMRI does all it's serial IO > using +only+ byte values. It's a but of a pain, as Java wants to go > to char and int types a little too aggressively, but it does solve > the "uncontrolled conversions" problems. Anytime that you are reading bytes of data that is not printable, unicode text, in Java, you really need to stay away from the Readers. Use input stream only, or you will see unicode valued byte groups converted to unicode "char" values. Gregg Wonderly From joachim at buechse.de Mon Mar 5 04:23:48 2007 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 5 Mar 2007 12:23:48 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> The behaviour is exactly what you asked for in you code. is = new BufferedReader(new InputStreamReader(port.getInputStream())); Readers return Text (ie unicode chars) not bytes. You instantiate the InputStreamReader without saying which charset you want, which means "platform default". As this is on Windows, it will convert Windows characters to equivalent unicode characters. If you want to read bytes, read bytes not Text. Reading bytes is done with InputStream and BufferedInputStream. BTW: The InputStream and Reader methods that read arrays are not guarenteed to fill up the array. You always have to check what you really got, and advance your index accordingly. A typical "read up to 32k" method looks like this: InputStream is= ... // -- determine the max buffer size int len= is.available(); if (len == 0) { len= 32 * 1024; } // -- read all available data byte[] buffer= new byte[len]; int pos= 0; int read; do { read= is.read(buffer, pos, buffer.length - pos); pos= pos + read; } while (read != -1 && pos < buffer.length); Best regards, Joachim --- Joachim B?chse Phone: +41 44 500 2604 Buechse Consulting Hadlaubsteig 2 CH-8006 Z?rich On 03.03.2007, at 23:10, Keith wrote: > Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > > Bob -- I think you hit the nail on the head. > > I was just coming to the same realization here. I knew that > something funny > was going on because the same bytes always got "corrupted." > > I'm pretty sure its in the InputStreamReader() functionality where the > conversion junk is happening. > > Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > > I don't know if simply changing the cast is going to work. Since the > conversion is happening upstream (pun intended), I don't think my > cast is > doing this. Also I think the compiler forced me to use the cast. > > I'm still playing around, and I'll report back once I nail it down. > > Thanks!! > > Keith > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Mon Mar 5 07:25:46 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 05 Mar 2007 08:25:46 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> Message-ID: <45EC286A.8060608@cox.net> Joachim Buechse wrote: > BTW: The InputStream and Reader methods that read arrays are not > guarenteed to fill up the array. You always have to check what you > really got, and advance your index accordingly. A typical "read up to > 32k" method looks like this: > > InputStream is= ... > // -- determine the max buffer size > int len= is.available(); > if (len == 0) { > len= 32 * 1024; > } > // -- read all available data > byte[] buffer= new byte[len]; > int pos= 0; > int read; > do { > read= is.read(buffer, pos, buffer.length - pos); > pos= pos + read; > } while (read != -1 && pos < buffer.length); > My preferred structure is. byte arr[ len ]; int cnt; int off = 0; while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { off += cnt; } This keeps you from adding -1 to pos when the read returns -1. It also skips out when the read is 0 bytes which, is not a described EOF in InputStream java docs, but is a condition I want to be aware of. Gregg Wonderly From joachim at buechse.de Tue Mar 6 02:52:58 2007 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 6 Mar 2007 10:52:58 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <45EC286A.8060608@cox.net> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: The code I copied was from a file resource reader, it shouldn't really be applied to networking/external IO code. Mea culpa. However aborting when you get 0 from read is not always what you want either (you kind of indicated that already). Some unix java implementations will return 0 if the kernel read was aborted with EINTER, which is rarely the point where you want to abort your read - at least not without further checks. A "complete" solution always depends on the events you need to handle and the time the total read could take in reality. In some cases it's worth checking Thread.isInterrupted() in the loop, some code re-loops on 0 but only a limited number of times, some check a total timeout limit, etc... Best regards, Joachim On 05.03.2007, at 15:25, Gregg Wonderly wrote: > My preferred structure is. > > byte arr[ len ]; > int cnt; > int off = 0; > while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { > off += cnt; > } > > This keeps you from adding -1 to pos when the read returns -1. It > also skips > out when the read is 0 bytes which, is not a described EOF in > InputStream java > docs, but is a condition I want to be aware of. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Mar 6 14:47:44 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 Mar 2007 14:47:44 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: Just FYI, rxtx will usually not break out on EINTER. The code in the native library usually does something close to this: do { read(...) } while ( !done && errno==EINTR ); Obviously there is a little more involved but it will retry on EINTER if not done. On Tue, 6 Mar 2007, Joachim Buechse wrote: > The code I copied was from a file resource reader, it shouldn't > really be applied to networking/external IO code. Mea culpa. > > However aborting when you get 0 from read is not always what you want > either (you kind of indicated that already). Some unix java > implementations will return 0 if the kernel read was aborted with > EINTER, which is rarely the point where you want to abort your read - > at least not without further checks. A "complete" solution always > depends on the events you need to handle and the time the total read > could take in reality. In some cases it's worth checking > Thread.isInterrupted() in the loop, some code re-loops on 0 but only > a limited number of times, some check a total timeout limit, etc... > > Best regards, > Joachim > > On 05.03.2007, at 15:25, Gregg Wonderly wrote: >> My preferred structure is. >> >> byte arr[ len ]; >> int cnt; >> int off = 0; >> while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { >> off += cnt; >> } >> >> This keeps you from adding -1 to pos when the read returns -1. It >> also skips >> out when the read is 0 bytes which, is not a described EOF in >> InputStream java >> docs, but is a condition I want to be aware of. >> >> Gregg Wonderly >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 gjhanna at gmail.com Thu Mar 8 13:42:52 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Fri, 9 Mar 2007 09:42:52 +1300 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? Message-ID: I've just struck an issue using rxtx in a multi-threaded environment: If I have 3 threads trying to open *the same* comm-port I get a deadlock in CommPortIdentifier.open If I have just 2, it works fine - I get a PortInUseException which is nice and I can handle it. The 3 thread->deadlock thing is causing me issues. (Sample code below). This is from the java thread-dump Found one Java-level deadlock: ============================= "Thread-2": waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object ), which is held by "Thread-1" "Thread-1": waiting to lock monitor 0x0003e9cc (object 0x2450e108, a gnu.io.CommPortIdentifier), which is held by "Thread-2" Java stack information for the threads listed above: =================================================== "Thread-2": at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:329) - waiting to lock <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) "Thread-1": at java.lang.Object.wait(Native Method) - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) - locked <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) (Apart from this, rxtx is working fantastically for us). I'm thinking I'll have to implement some sort of locking mechanism that *doesn't* use java synchronization to prevent this situation. (Which doesn't sound like a good idea to me). Any ideas? Thanks, Greg Hanna ============= RXTXLockTest.java ======================================== import gnu.io.CommPort; import gnu.io.CommPortIdentifier; /** * @author Greg Hanna * Minimal code to create a deadlock with rxtx in multithreaded open */ public class RXTXLockTest { public static void main(String[] args) { try { CommPortIdentifier cpiCom1 = CommPortIdentifier.getPortIdentifier ("COM14"); OpenThread t1 = new OpenThread (" one ", cpiCom1); OpenThread t2 = new OpenThread (" two ", cpiCom1); OpenThread t3 = new OpenThread (" 003 ", cpiCom1); t1.start(); t2.start(); t3.start(); // comment this out and it runs with (expected) PortInUseException } catch (Exception e) { e.printStackTrace(); } } } class OpenThread extends Thread { String name; CommPortIdentifier cpi; CommPort cp; public OpenThread (String name, CommPortIdentifier cpi) { this.name = name; this.cpi = cpi; System.out.println (System.currentTimeMillis() + name + " thread created"); } public void run () { try { System.out.println (System.currentTimeMillis() + name + " opening"); cp = cpi.open(name, 2000); System.out.println (System.currentTimeMillis() + name + " opened - sleeping"); sleep (2000); // do the serial comms with the device. System.out.println (System.currentTimeMillis() + name + " slept - closing"); cp.close(); System.out.println (System.currentTimeMillis() + name + " closed - exiting"); } catch (Exception e) { System.out.println ("Error in thread: " + name ); e.printStackTrace(); } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070308/d9a163c5/attachment-0088.html From eu259473 at tele2.it Fri Mar 9 02:46:20 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 09 Mar 2007 10:46:20 +0100 Subject: [Rxtx] rxtx: tru64 unix make fails Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070309/3b654523/attachment-0088.html From lyon at docjava.com Fri Mar 9 03:58:32 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 Mar 2007 05:58:32 -0500 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi All, The deadlock issue is one that I have been thinking about for some time now. It seems to me that we need a resource manager that enables assignment to a known process. The one thing that seems important about serial ports is that two applications should not use the same serial port at the same time. When this happens, it throws an exception. OK. The exception is a response to a lock condition that arises from an unavailable resource. An abstract implementation (not born of native methods) might assign a serial port to an application, until the application releases it (or is forced to release it by some kill mechanism). Some resources (like a registry) can be reused. But others, like the serial port, cannot. In the case of the serial port, we would like, I think, to have the flyweight design pattern without sharing and with object assignment tracking. A means of breaking deadlock (like a leasing mechanism) seems very useful, to me. My guess is that we can serialize the state of the Parametric Singleton Pattern (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) into the Preferences of the System. Preferences.systemRoot() might help with that. When a resource is checked out, the lease time and owner are listed. A thread that does this can be killed, but applications outside of Java are problematic. There is a compelling problem here. It is not just serial ports. Sound cards, cameras, microphones, files, tape drives, etc. All are consumed resources that are assigned to an application (or user) and deprive other applications, or users, from use. What, if anything, should we do? At present we throw PortInUseExceptions. Is that it? Can we do better? OK, the port is in use. Now what? Do I have to be root to go remove lock files and kill applications? Is there a better way? Thanks! - Doug >I've just struck an issue using rxtx in a multi-threaded environment: > >If I have 3 threads trying to open *the same* >comm-port I get a deadlock in >CommPortIdentifier.open >If I have just 2, it works fine - I get a >PortInUseException which is nice and I can >handle it. > >The 3 thread->deadlock thing is causing me issues. >(Sample code below). > >This is from the java thread-dump > >Found one Java-level deadlock: >============================= >"Thread-2": > waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), > which is held by "Thread-1" >"Thread-1": > waiting to lock monitor 0x0003e9cc (object >0x2450e108, a gnu.io.CommPortIdentifier ), > which is held by "Thread-2" > >Java stack information for the threads listed above: >=================================================== >"Thread-2": > at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) > - waiting to lock <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) >"Thread-1": > at java.lang.Object.wait(Native Method) > - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) > - locked <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) > > >(Apart from this, rxtx is working fantastically for us). > >I'm thinking I'll have to implement some sort of >locking mechanism that *doesn't* use java >synchronization to prevent this situation. >(Which doesn't sound like a good idea to me). > >Any ideas? > >Thanks, > >Greg Hanna > >============= RXTXLockTest.java ======================================== > >import gnu.io.CommPort; >import gnu.io.CommPortIdentifier; > >/** > * @author Greg Hanna > * Minimal code to create a deadlock with rxtx in multithreaded open > */ >public class RXTXLockTest { > ? > ?public static void main(String[] args) { > ?try { > ?CommPortIdentifier cpiCom1 = >CommPortIdentifier.getPortIdentifier ("COM14"); > ?OpenThread t1 = new OpenThread (" one ", cpiCom1); > ?OpenThread t2 = new OpenThread (" two ", cpiCom1); > ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); > ?t1.start(); > ?t2.start(); > ?t3.start(); // comment this out >and it runs with (expected) PortInUseException > ?} catch (Exception e) { > ?e.printStackTrace(); > ?} > ?} >} > >class OpenThread extends Thread { > ?String name; > ?CommPortIdentifier cpi; > ?CommPort cp; > ?public OpenThread (String name, CommPortIdentifier cpi) { > ? this.name = name; > ?this.cpi = cpi; > ?System.out.println >(System.currentTimeMillis() + name + " thread >created"); > ?} > ?public void run () { > ?try { > ?System.out.println >(System.currentTimeMillis() + name + " opening"); > ?cp = cpi.open(name, 2000); > ?System.out.println >(System.currentTimeMillis() + name + " opened - >sleeping"); > ?sleep (2000); // do the serial comms with the device. > ?System.out.println >(System.currentTimeMillis() + name + " slept - >closing"); > ?cp.close(); > ?System.out.println >(System.currentTimeMillis() + name + " closed - >exiting"); > ?} catch (Exception e) { > System.out.println ("Error in thread: " + name ); > ?e.printStackTrace(); > ?} > ?} >} > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Mar 9 06:37:45 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 Mar 2007 06:37:45 -0700 (MST) Subject: [Rxtx] rxtx: tru64 unix make fails In-Reply-To: References: Message-ID: On Fri, 9 Mar 2007, "Giuseppe Marchese" wrote: > Sorry for delay. > ? > This is log for ./configure and make > error. > ? > thanks for attention > ? > Make: '%.java,$(TOP)/$(CLASSDEST)/%.class,$(wildcard $(SPATH)/*.java)': extra chars.? > Stop. > Hi Giuseppe You need to use GNU make with the Makefile. I suspect the tru64 make is not happy with those rules. > configure: exit 0 Looks like configure is fairly happy. From tjarvi at qbang.org Sat Mar 10 07:43:51 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 07:43:51 -0700 (MST) Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi Doug I have very little time to look into this further but what we could do is open up an rxtx 3 devel branch in which a proof of concept could be worked on. It could be the proof of concept for a JSR others including Sun could look at/work on or parts of it could be recycled in a JSR. I'm working very hard on rxtx right now but it does not show. I'm looking at win64, mac intel/ppc, usb bluetooth and usb serial dongles. Some are going to be more tested than others but they are all on the plate. I'll be pushing all the fixes upstream when they are done. So I'm very busy in 2.1 but we could open a new branch. On Fri, 9 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > The deadlock issue is one that I have been thinking about > for some time now. > It seems to me that we need a resource manager that enables assignment > to a known process. > > The one thing that seems important about serial > ports is that two applications should not use the > same serial port at the same time. When this > happens, it throws an exception. > OK. > > The exception is a response to a lock condition that > arises from an unavailable resource. > > An abstract implementation (not born of native methods) might > assign a serial port to an application, until the > application releases it (or is forced to release > it by some kill mechanism). > > Some resources (like a registry) can be reused. > But others, like the serial port, > cannot. > > In the case of the serial port, we would like, I think, to > have the flyweight design pattern > without sharing and with object assignment tracking. > A means of breaking deadlock (like a leasing > mechanism) seems very useful, to me. > > My guess is that we can serialize the state of the Parametric Singleton Pattern > (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) > into the Preferences of the System. Preferences.systemRoot() might help > with that. When a resource is checked out, the lease time and owner are > listed. A thread that does this can be killed, but applications outside of Java > are problematic. > > There is a compelling problem here. It is not just serial ports. > Sound cards, cameras, microphones, files, tape drives, etc. All are consumed > resources that are assigned to an application (or > user) and deprive other applications, > or users, from use. > > What, if anything, should we do? At present we throw PortInUseExceptions. > Is that it? > Can we do better? > OK, the port is in use. Now what? > Do I have to be root to go remove lock files and kill applications? > Is there a better way? > > Thanks! > - Doug > >> I've just struck an issue using rxtx in a multi-threaded environment: >> >> If I have 3 threads trying to open *the same* >> comm-port I get a deadlock in >> CommPortIdentifier.open >> If I have just 2, it works fine - I get a >> PortInUseException which is nice and I can >> handle it. >> >> The 3 thread->deadlock thing is causing me issues. >> (Sample code below). >> >> This is from the java thread-dump >> >> Found one Java-level deadlock: >> ============================= >> "Thread-2": >> waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), >> which is held by "Thread-1" >> "Thread-1": >> waiting to lock monitor 0x0003e9cc (object >> 0x2450e108, a gnu.io.CommPortIdentifier ), >> which is held by "Thread-2" >> >> Java stack information for the threads listed above: >> =================================================== >> "Thread-2": >> at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) >> - waiting to lock <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> "Thread-1": >> at java.lang.Object.wait(Native Method) >> - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) >> - locked <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> >> >> (Apart from this, rxtx is working fantastically for us). >> >> I'm thinking I'll have to implement some sort of >> locking mechanism that *doesn't* use java >> synchronization to prevent this situation. >> (Which doesn't sound like a good idea to me). >> >> Any ideas? >> >> Thanks, >> >> Greg Hanna >> >> ============= RXTXLockTest.java ======================================== >> >> import gnu.io.CommPort; >> import gnu.io.CommPortIdentifier; >> >> /** >> * @author Greg Hanna >> * Minimal code to create a deadlock with rxtx in multithreaded open >> */ >> public class RXTXLockTest { >> ? >> ?public static void main(String[] args) { >> ?try { >> ?CommPortIdentifier cpiCom1 = >> CommPortIdentifier.getPortIdentifier ("COM14"); >> ?OpenThread t1 = new OpenThread (" one ", cpiCom1); >> ?OpenThread t2 = new OpenThread (" two ", cpiCom1); >> ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); >> ?t1.start(); >> ?t2.start(); >> ?t3.start(); // comment this out >> and it runs with (expected) PortInUseException >> ?} catch (Exception e) { >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> class OpenThread extends Thread { >> ?String name; >> ?CommPortIdentifier cpi; >> ?CommPort cp; >> ?public OpenThread (String name, CommPortIdentifier cpi) { >> ? this.name = name; >> ?this.cpi = cpi; >> ?System.out.println >> (System.currentTimeMillis() + name + " thread >> created"); >> ?} >> ?public void run () { >> ?try { >> ?System.out.println >> (System.currentTimeMillis() + name + " opening"); >> ?cp = cpi.open(name, 2000); >> ?System.out.println >> (System.currentTimeMillis() + name + " opened - >> sleeping"); >> ?sleep (2000); // do the serial comms with the device. >> ?System.out.println >> (System.currentTimeMillis() + name + " slept - >> closing"); >> ?cp.close(); >> ?System.out.println >> (System.currentTimeMillis() + name + " closed - >> exiting"); >> ?} catch (Exception e) { >> System.out.println ("Error in thread: " + name ); >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 mm at UDel.Edu Sat Mar 10 14:48:32 2007 From: mm at UDel.Edu (Mike Markowski) Date: Sat, 10 Mar 2007 16:48:32 -0500 Subject: [Rxtx] rxtx and Sun's comm api Message-ID: <45F327B0.2060004@udel.edu> Hi all, I joined the list a few days ago and apologize for what is likely a frequently asked question, though I haven't yet found it anywhere. I learned about rxtx.org through the readme on Sun's version 2 of their comms api. They give recommendations in that readme regarding how a better comms api should be written. Is this the aim of rxtx.org? I wrote an app on my linux box using the Sun comms api (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the fact that only linux and Solaris are supported. So I'm glad to find rxtx.org and am just reading up on how make the conversion so Windows users will be able to run the program as well. At the same time I'm just curious if rxtx.org and Sun are both heading in the same direction. Thanks for any background or historical info. Feel free to point me to any www pages if my googling has just completely missed the target! Thanks again, Mike From tjarvi at qbang.org Sat Mar 10 15:35:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 15:35:25 -0700 (MST) Subject: [Rxtx] rxtx and Sun's comm api In-Reply-To: <45F327B0.2060004@udel.edu> References: <45F327B0.2060004@udel.edu> Message-ID: On Sat, 10 Mar 2007, Mike Markowski wrote: > Hi all, > > I joined the list a few days ago and apologize for what is likely a > frequently asked question, though I haven't yet found it anywhere. I > learned about rxtx.org through the readme on Sun's version 2 of their > comms api. They give recommendations in that readme regarding how a > better comms api should be written. Is this the aim of rxtx.org? > > I wrote an app on my linux box using the Sun comms api > (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the > fact that only linux and Solaris are supported. So I'm glad to find > rxtx.org and am just reading up on how make the conversion so Windows > users will be able to run the program as well. At the same time I'm > just curious if rxtx.org and Sun are both heading in the same direction. > > Thanks for any background or historical info. Feel free to point me to > any www pages if my googling has just completely missed the target! > I do not have any news (good or bad) concerning RXTX and Sun working together but perhaps others here do. The main goal of RXTX is to expose POSIX termios interfaces to java users. The future support of javax.comm is questionable. We do not have resources for everything. gnu.io (RXTX 2.1) will be supported going forward and functions the same as CommAPI 2.0. If you have control of the source code you are working with, I would not advise using CommAPI 2.0 javax.comm. We do support CommAPI 2.0 javax.comm for older applications but I do not think that will last much longer for practical reasons. The download interest in CommAPI 2.0 javax.comm support is becomming negligible on this end. There has been discussion of a JSR effort but I do not know of any status change since it was mentioned. One problem with a JSR is that even a light weight process is going to be difficult for RXTX at this time. Maybe that will change in the future but then again it may not. For now, we are just going forward 'as is' in rxtx 2.1 with package gnu.io while trying as a secondary effort to backport the changes to rxtx 2.0 for javax.comm support for users that do not have a choice. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Mar 11 07:19:40 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 11 Mar 2007 08:19:40 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: Hi All, I have been a proponent of a JSR that makes use of RXTX. I have executed the proper agreements with Sun. At this point we are in the: Early Draft Review of Draft Specifications Stage. The best thing to do is to enter the quiet period and create a specification. The question of exactly how we, as a group, want to approach this problem, remains open. Typically, we should have both a specification and a reference implementation. Thus, it would be to our best advantage to have a nice, stable, cross platform RXTX distro that adheres to the groups specification. Now, from a specification standpoint, my personal view on the matter is that we create a series of interfaces, with nice documentation (or at least javadoc). Is this a good idea? Should we have a pure interface specification for the communication API? There are several issues, in my mind, which still weigh on us. Hot-pluggable dongles, long discovery process on pop-up ports, lack of uniformity on device names, lack of uniformity on locking, a precise understanding of how the SerialPortResourceManager works (or even if we should have one). The more questions we answer in our reference implementation, the better our specification will get. RXTX is a good working prototype, but, I don't know if that is what we want to use for a specification. Here is what I have for a CommPortInterface: */ public interface CommPortInterface { /** * @return a string representation of this port. */ String toString(); /** * Gets the name of the communications port. This name should correspond to * something the user can identify, like the label on the hardware. * @return name of the port */ String getName(); /** * @return an input stream that can be used to read data from the * communications port. If the port doesn't support reading data, this * method returns null. *

* The blocking behaviour of this input stream depends on the threshold * and timeout values, as shown below for a read buffer size of n * bytes: * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ThresholdTimeoutBlocking behaviour
StateValueStateValue
disableddisabledblock until data is available
enabledm bytesdisabledblock until min(m, n) bytes are available
disabledenabledt msblock for t ms or until data is available
enabledm bytesenabledt msblock for t ms or until min(m, n) bytes are * available
* @throws java.io.IOException */ InputStream getInputStream() throws IOException; /** * @return an output stream that can be used to send data to the * communications port. If the port doesn't support sending data, this * method returns null. * @throws java.io.IOException */ OutputStream getOutputStream() throws IOException; /** * Closes this communications port. * All PortOwnershipListeners will be? * notified of this change of ownership. Further method calls on this? * object will throw IllegalStateException. Further calls on the? * associated InputStream or OutputStream will throw IOException. *

* Close does not block. Undelivered data is discarded. Blocked read and? * write operations are aborted if the underlying operating systems? * supports an IO abort mechanism. To await the delivery of undelivered? * data call OutputStream.flush() or OutputStream.close() before calling? * Port.close(). */ void close(); /** * Enables receive threshold. * When the specified threshold number of bytes are retrieved, read will * return immediately. * * @param thresh the number of bytes in the input buffer * @throws gnu.io.UnsupportedCommOperationException * if receive threshold is * not supported by the driver * @see #disableReceiveThreshold */ void enableReceiveThreshold(int thresh) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive threshold. * * @see #enableReceiveThreshold */ void disableReceiveThreshold(); /** * @return true if receive threshold is enabled. * * @see #enableReceiveThreshold */ boolean isReceiveThresholdEnabled(); /** * @return the receive threshold value. If receive threshold is diabled * or not supported, this value is meaningless. * * @see #enableReceiveThreshold */ int getReceiveThreshold(); /** * Enables receive timeout. * When the specified number of milliseconds have elapsed, read will * return immediately. * * @param rcvTimeout the number of milliseconds to block for * @throws gnu.io.UnsupportedCommOperationException * if receive timeout is * not supported by the driver * @see #disableReceiveTimeout */ void enableReceiveTimeout(int rcvTimeout) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive timeout. * * @see #enableReceiveTimeout */ void disableReceiveTimeout(); /** * @return true if receive timeout is enabled. * * @see #enableReceiveTimeout */ boolean isReceiveTimeoutEnabled(); /** * @return the receive timeout value. If receive timeout is diabled * or not supported, this value is meaningless. * * @see #enableReceiveTimeout */ int getReceiveTimeout(); /** * Enables receive framing. * The supplied byte value in the input suggests the end of the received * frame, and read returns immediately. Only the low 8 bits of the * supplied value are significant. * * @param framingByte the frame delimiter * @throws gnu.io.UnsupportedCommOperationException * if receive framing is * not supported by the driver * @see #disableReceiveFraming */ void enableReceiveFraming(int framingByte) throws UnsupportedCommOperationException; /** * Disables receive framing. * * @see #enableReceiveFraming */ void disableReceiveFraming(); /** * @return true if receive framing is enabled. * * @see #enableReceiveFraming */ boolean isReceiveFramingEnabled(); /** * @return true if receive framing byte. If receive framing is diabled * or not supported, this value is meaningless. * * @see #enableReceiveFraming */ int getReceiveFramingByte(); /** * Sets the input buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setInputBufferSize(int size); /** * @return the input buffer size. * The driver may choose not to report correct values. */ int getInputBufferSize(); /** * Sets the output buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setOutputBufferSize(int size); /** * @return the output buffer size. * The driver may choose not to report correct values. */ int getOutputBufferSize(); } What do you think of that? Note the wishy washy nature of the spec: The driver may choose to ignore this method. Is that good enough for us? Thanks! - Doug From ra85551 at gmail.com Sun Mar 11 08:44:45 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Sun, 11 Mar 2007 17:44:45 +0300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hello, world! I am writing application that communicates with modem via AT commands. My OS is Linux Kubuntu Feisty Herd, to ensure that my application will run properly under Windows XP I installed VMWare server. When I tried to send AT command and evaluate modem answer under WinXP @ VMWare server, I actually didn't receive anything. I think that VM settings are right, because I do can communicate with modem by using standard HyperTerminall as well as I can do on native Windows. So, why RXTX doesn't work under VM, but works under Linux and pure Windows XP (i tested it there) well? The send/receive method code follows. private String sendATCommand(String command, final String waitFor, final boolean isRegex, boolean isAddCRLF, long timeout) throws BeaconConnectException { final long POLL_PERIOD = 100; final int BUFFER_SIZE = 512; final byte[] buffer = new byte[BUFFER_SIZE]; final InputStream serialInput; final OutputStream serialOutput; try { serialInput = serialPort.getInputStream(); if (command != null) { serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } } catch (IOException e) { throw new MyException("serial I/O error"); } TimerTask task = new TimerTask() { int offset = 0; int bytesRead; public synchronized void run() { try { if (serialInput.available() > 0) { bytesRead = serialInput.read(buffer, offset, BUFFER_SIZE - offset); } else { return; } } catch (IOException e) { // do nothing - maybe next time we'll read something } offset += bytesRead; if (waitFor != null) { String temporary = new String(buffer, 0, offset).trim(); if (isRegex && temporary.matches(waitFor) || temporary.contains(waitFor)) { cancel(); notify(); } } } }; Timer timer = new Timer(); timer.schedule(task, POLL_PERIOD, POLL_PERIOD); synchronized (task) { try { task.wait(timeout); task.cancel(); } catch (InterruptedException e) { } } //Cut off leading and trailing CRs, LFs and zeroes String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); System.out.println(response); return response; } -- Pavel Parkhomenko From tjarvi at qbang.org Sun Mar 11 11:48:22 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:48:22 -0600 (MDT) Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: On Sun, 11 Mar 2007, Pavel Parkhomenko wrote: > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. > > private String sendATCommand(String command, final String waitFor, > final boolean isRegex, boolean isAddCRLF, long timeout) > throws BeaconConnectException > { > final long POLL_PERIOD = 100; > final int BUFFER_SIZE = 512; > final byte[] buffer = new byte[BUFFER_SIZE]; > final InputStream serialInput; > final OutputStream serialOutput; > try > { > serialInput = serialPort.getInputStream(); > if (command != null) > { > serialOutput = serialPort.getOutputStream(); > if (isAddCRLF) > { > command += "\r\n"; > } > System.out.println(command); > serialOutput.write(command.getBytes()); > } > } > catch (IOException e) > { > throw new MyException("serial I/O error"); > } > > TimerTask task = new TimerTask() > { > int offset = 0; > int bytesRead; > public synchronized void run() > { > try > { > if (serialInput.available() > 0) > { > bytesRead = serialInput.read(buffer, offset, > BUFFER_SIZE - offset); > } > else > { > return; > } > } > catch (IOException e) > { > // do nothing - maybe next time we'll read something > } > offset += bytesRead; > if (waitFor != null) > { > String temporary = new String(buffer, 0, offset).trim(); > if (isRegex && temporary.matches(waitFor) || > temporary.contains(waitFor)) > { > cancel(); > notify(); > } > } > } > }; > > Timer timer = new Timer(); > timer.schedule(task, POLL_PERIOD, POLL_PERIOD); > synchronized (task) { > try > { > task.wait(timeout); > task.cancel(); > } > catch (InterruptedException e) > { > } > } > //Cut off leading and trailing CRs, LFs and zeroes > String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); > System.out.println(response); > return response; > } > > > Hi Pavel VMWare should not be a problem. I've used it in the past - though not with a modem. Make sure nothing else is using the modem. Then look in the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an example that should work. Note that modems could care less what OS is on top. If you are trying to match new lines to the OS and sending it to the mode for AT commands, thats probably a mistake. Also it would not hurt to print out the individual bytes that you are sending to make sure they did not get mangled along the path. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 11:55:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:55:48 -0600 (MDT) Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: On Sun, 11 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > I have been a proponent of a JSR that makes > use of RXTX. I have executed the proper agreements with Sun. > > At this point we are in the: > Early Draft Review of Draft Specifications Stage. > > The best thing to do is to enter the quiet period and create > a specification. The question of exactly how we, as a group, > want to approach this problem, remains open. > > Typically, we should have both a specification and a reference > implementation. Thus, it would be to our best advantage to have > a nice, stable, cross platform RXTX distro that adheres to the > groups specification. > > Now, from a specification standpoint, my personal view on the matter is > that we create a series of interfaces, with nice documentation (or at least > javadoc). > > Is this a good idea? Should we have a pure interface specification for > the communication API? > > There are several issues, in my mind, which still weigh on us. > Hot-pluggable dongles, long discovery process on pop-up ports, > lack of uniformity on device names, lack of uniformity on locking, > a precise understanding of how the SerialPortResourceManager > works (or even if we should have one). > > The more questions we answer in our reference implementation, the > better our specification will get. RXTX is a good working prototype, > but, I don't know if that is what we want to use for a specification. > > Here is what I have for a CommPortInterface: > */ > public interface CommPortInterface { Hi Doug, I can start going through the method interfaces later this week and giving feedback. I would suggest that the JSR should not be too generic in nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel drivers that intend to look like EIA232 ports at the kernel driver level. some ideas: EIA232PortInterface TermiosInterface SerialPortInterface Something that differentiates this from thing like USB, I2C, ... which should not have to deal with legacy serial claiming to be the comm api. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 12:52:19 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 12:52:19 -0600 (MDT) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: No news is good news with these posts. I'll start the process of pinging legal a week from Monday on my end if nobody has objections to the proposal. I just want to make sure everyone has time to raise objections. Obviously, anyone can fork from a previous version if they don't like the new license. I suspect we can avoid that though. On Sun, 4 Mar 2007, Trent Jarvi wrote: > > For those that are wondering what is going on here, this > next bit is the meat of the changes. We agreed a long time > ago to put this disclaimer in. We did a so so job. It was > in rxtx 2.0, not well written, ... So some groups using > rxtx that would like to ship rxtx so users don't need to > download, install, go to the mail-list to find why it failed, > ... Then their legal teams tell them section 5 paragraph 2 > is a show stopper. > > That was never the intent. > > > Now going through what remains... > >> and might need a (TM) suffix to make Sun happy. > > Added disclaimer at the ended 'all trademarks belong...' > >> * Line #15ff - static vs. dynamic linking - you did >> not transcribe the text from the "controlled >> interface exception" when writing this text - and >> this was good so, because these terms originally >> refer to the GPL rather than the LGPL. I think though, >> that these 4 lines are the most important ones and >> should thus be really really clear. I hope that I >> meet your original intent with the following >> suggestions: >> 1.) Instead of "A program.." it would be better to >> say "An exectuable.." in order to be closer to >> the LGPL text. > > OK. As you can see I was trying to adjust GNU text there > for the LGPL. > >> 2.) It would be better to say .. "by being dynamically >> linked with it" to clearly indicate that dynamic >> linking is meant. The matter of compilation is >> already covered by the LGPL so mentioning it again >> just leads to confusion. > > used dynamically linked terminology. > >> 3.) It would be better to say .. "is considered a >> work that uses the library in contrast to section >> 5 of the LGPL, so the terms of the LGPL do not >> apply to the resulting executable". > > I tried to address this more upfront with an intent statement. > Let me know if you have problems with it. I also tried to > make it a little more clear what was derived from the GNU > solution by moving the link location closer to GNU's suggestion. > >> >> Note that LGPL section 5 says: ..."is called a >> "work that uses the Library". Such a work, in isolation, >> is not a derivative work of the Library, and therefore >> falls outside the scope of this License." >> The next paragraph of the LGPL is exactly the problematic >> one that I hope is clarified by the exception terms you >> give. >> > > Thats the intent. Here is the combined fixes. Note that only the > material in /*-- --*/ is being touched. The new GPL license is > there but unmodified. > > > ------------------------ begin proposed new license ------------------- > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Lesser General Public > | License as published by the Free Software Foundation; either > | version 2.1 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Lesser General Public License for more details. > | > | An executable that contains no derivative of any portion of RXTX, but > | is designed to work with RXTX by being dynamically linked with it, > | is considered a "work that uses the Library" subject to the terms and > | conditions of the GNU Lesser General Public License. > | > | The following has been added to the RXTX License to remove > | any confusion about linking to RXTX. We want to allow in part what > | section 5, paragraph 2 of the LGPL does not permit in the special > | case of linking over a controlled interface. The intent is to add a > | Java Specification Request or standards body defined interface in the > | future as another exception but one is not currently available. > | > | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface > | > | As a special exception, the copyright holders of RXTX give you > | permission to link RXTX with independent modules that communicate with > | RXTX solely through the Sun Microsytems CommAPI interface version 2, > | regardless of the license terms of these independent modules, and to copy > | and distribute the resulting combined work under terms of your choice, > | provided that every copy of the combined work is accompanied by a complete > | copy of the source code of RXTX (the version of RXTX used to produce the > | combined work), being distributed under the terms of the GNU Lesser General > | Public License plus this exception. An independent module is a > | module which is not derived from or based on RXTX. > | > | Note that people who make modified versions of RXTX are not obligated > | to grant this special exception for their modified versions; it is > | their choice whether to do so. The GNU Lesser General Public License > | gives permission to release a modified version without this exception; this > | exception also makes it possible to release a modified version which > | carries forward this exception. > | > | You should have received a copy of the GNU Lesser General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > | All trademarks belong to their respective owners. > --------------------------------------------------------------------------*/ > > The original GNU Lesser General Public License Follows. > > > GNU LESSER GENERAL PUBLIC LICENSE > Version 2.1, February 1999 > > Copyright (C) 1991, 1999 Free Software Foundation, Inc. > 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > Everyone is permitted to copy and distribute verbatim copies > of this license document, but changing it is not allowed. > > [This is the first released version of the Lesser GPL. It also counts > as the successor of the GNU Library Public License, version 2, hence > the version number 2.1.] > > Preamble > > The licenses for most software are designed to take away your > freedom to share and change it. By contrast, the GNU General Public > Licenses are intended to guarantee your freedom to share and change > free software--to make sure the software is free for all its users. > > This license, the Lesser General Public License, applies to some > specially designated software packages--typically libraries--of the > Free Software Foundation and other authors who decide to use it. You > can use it too, but we suggest you first think carefully about whether > this license or the ordinary General Public License is the better > strategy to use in any particular case, based on the explanations below. > > When we speak of free software, we are referring to freedom of use, > not price. Our General Public Licenses are designed to make sure that > you have the freedom to distribute copies of free software (and charge > for this service if you wish); that you receive source code or can get > it if you want it; that you can change the software and use pieces of > it in new free programs; and that you are informed that you can do > these things. > > To protect your rights, we need to make restrictions that forbid > distributors to deny you these rights or to ask you to surrender these > rights. These restrictions translate to certain responsibilities for > you if you distribute copies of the library or if you modify it. > > For example, if you distribute copies of the library, whether gratis > or for a fee, you must give the recipients all the rights that we gave > you. You must make sure that they, too, receive or can get the source > code. If you link other code with the library, you must provide > complete object files to the recipients, so that they can relink them > with the library after making changes to the library and recompiling > it. And you must show them these terms so they know their rights. > > We protect your rights with a two-step method: (1) we copyright the > library, and (2) we offer you this license, which gives you legal > permission to copy, distribute and/or modify the library. > > To protect each distributor, we want to make it very clear that > there is no warranty for the free library. Also, if the library is > modified by someone else and passed on, the recipients should know > that what they have is not the original version, so that the original > author's reputation will not be affected by problems that might be > introduced by others. > > Finally, software patents pose a constant threat to the existence of > any free program. We wish to make sure that a company cannot > effectively restrict the users of a free program by obtaining a > restrictive license from a patent holder. Therefore, we insist that > any patent license obtained for a version of the library must be > consistent with the full freedom of use specified in this license. > > Most GNU software, including some libraries, is covered by the > ordinary GNU General Public License. This license, the GNU Lesser > General Public License, applies to certain designated libraries, and > is quite different from the ordinary General Public License. We use > this license for certain libraries in order to permit linking those > libraries into non-free programs. > > When a program is linked with a library, whether statically or using > a shared library, the combination of the two is legally speaking a > combined work, a derivative of the original library. The ordinary > General Public License therefore permits such linking only if the > entire combination fits its criteria of freedom. The Lesser General > Public License permits more lax criteria for linking other code with > the library. > > We call this license the "Lesser" General Public License because it > does Less to protect the user's freedom than the ordinary General > Public License. It also provides other free software developers Less > of an advantage over competing non-free programs. These disadvantages > are the reason we use the ordinary General Public License for many > libraries. However, the Lesser license provides advantages in certain > special circumstances. > > For example, on rare occasions, there may be a special need to > encourage the widest possible use of a certain library, so that it becomes > a de-facto standard. To achieve this, non-free programs must be > allowed to use the library. A more frequent case is that a free > library does the same job as widely used non-free libraries. In this > case, there is little to gain by limiting the free library to free > software only, so we use the Lesser General Public License. > > In other cases, permission to use a particular library in non-free > programs enables a greater number of people to use a large body of > free software. For example, permission to use the GNU C Library in > non-free programs enables many more people to use the whole GNU > operating system, as well as its variant, the GNU/Linux operating > system. > > Although the Lesser General Public License is Less protective of the > users' freedom, it does ensure that the user of a program that is > linked with the Library has the freedom and the wherewithal to run > that program using a modified version of the Library. > > The precise terms and conditions for copying, distribution and > modification follow. Pay close attention to the difference between a > "work based on the library" and a "work that uses the library". The > former contains code derived from the library, whereas the latter must > be combined with the library in order to run. > > GNU LESSER GENERAL PUBLIC LICENSE > TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION > > 0. This License Agreement applies to any software library or other > program which contains a notice placed by the copyright holder or > other authorized party saying it may be distributed under the terms of > this Lesser General Public License (also called "this License"). > Each licensee is addressed as "you". > > A "library" means a collection of software functions and/or data > prepared so as to be conveniently linked with application programs > (which use some of those functions and data) to form executables. > > The "Library", below, refers to any such software library or work > which has been distributed under these terms. A "work based on the > Library" means either the Library or any derivative work under > copyright law: that is to say, a work containing the Library or a > portion of it, either verbatim or with modifications and/or translated > straightforwardly into another language. (Hereinafter, translation is > included without limitation in the term "modification".) > > "Source code" for a work means the preferred form of the work for > making modifications to it. For a library, complete source code means > all the source code for all modules it contains, plus any associated > interface definition files, plus the scripts used to control compilation > and installation of the library. > > Activities other than copying, distribution and modification are not > covered by this License; they are outside its scope. The act of > running a program using the Library is not restricted, and output from > such a program is covered only if its contents constitute a work based > on the Library (independent of the use of the Library in a tool for > writing it). Whether that is true depends on what the Library does > and what the program that uses the Library does. > > 1. You may copy and distribute verbatim copies of the Library's > complete source code as you receive it, in any medium, provided that > you conspicuously and appropriately publish on each copy an > appropriate copyright notice and disclaimer of warranty; keep intact > all the notices that refer to this License and to the absence of any > warranty; and distribute a copy of this License along with the > Library. > > You may charge a fee for the physical act of transferring a copy, > and you may at your option offer warranty protection in exchange for a > fee. > > 2. You may modify your copy or copies of the Library or any portion > of it, thus forming a work based on the Library, and copy and > distribute such modifications or work under the terms of Section 1 > above, provided that you also meet all of these conditions: > > a) The modified work must itself be a software library. > > b) You must cause the files modified to carry prominent notices > stating that you changed the files and the date of any change. > > c) You must cause the whole of the work to be licensed at no > charge to all third parties under the terms of this License. > > d) If a facility in the modified Library refers to a function or a > table of data to be supplied by an application program that uses > the facility, other than as an argument passed when the facility > is invoked, then you must make a good faith effort to ensure that, > in the event an application does not supply such function or > table, the facility still operates, and performs whatever part of > its purpose remains meaningful. > > (For example, a function in a library to compute square roots has > a purpose that is entirely well-defined independent of the > application. Therefore, Subsection 2d requires that any > application-supplied function or table used by this function must > be optional: if the application does not supply it, the square > root function must still compute square roots.) > > These requirements apply to the modified work as a whole. If > identifiable sections of that work are not derived from the Library, > and can be reasonably considered independent and separate works in > themselves, then this License, and its terms, do not apply to those > sections when you distribute them as separate works. But when you > distribute the same sections as part of a whole which is a work based > on the Library, the distribution of the whole must be on the terms of > this License, whose permissions for other licensees extend to the > entire whole, and thus to each and every part regardless of who wrote > it. > > Thus, it is not the intent of this section to claim rights or contest > your rights to work written entirely by you; rather, the intent is to > exercise the right to control the distribution of derivative or > collective works based on the Library. > > In addition, mere aggregation of another work not based on the Library > with the Library (or with a work based on the Library) on a volume of > a storage or distribution medium does not bring the other work under > the scope of this License. > > 3. You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. To do > this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version 2, > instead of to this License. (If a newer version than version 2 of the > ordinary GNU General Public License has appeared, then you can specify > that version instead if you wish.) Do not make any other change in > these notices. > > Once this change is made in a given copy, it is irreversible for > that copy, so the ordinary GNU General Public License applies to all > subsequent copies and derivative works made from that copy. > > This option is useful when you wish to copy part of the code of > the Library into a program that is not a library. > > 4. You may copy and distribute the Library (or a portion or > derivative of it, under Section 2) in object code or executable form > under the terms of Sections 1 and 2 above provided that you accompany > it with the complete corresponding machine-readable source code, which > must be distributed under the terms of Sections 1 and 2 above on a > medium customarily used for software interchange. > > If distribution of object code is made by offering access to copy > from a designated place, then offering equivalent access to copy the > source code from the same place satisfies the requirement to > distribute the source code, even though third parties are not > compelled to copy the source along with the object code. > > 5. A program that contains no derivative of any portion of the > Library, but is designed to work with the Library by being compiled or > linked with it, is called a "work that uses the Library". Such a > work, in isolation, is not a derivative work of the Library, and > therefore falls outside the scope of this License. > > However, linking a "work that uses the Library" with the Library > creates an executable that is a derivative of the Library (because it > contains portions of the Library), rather than a "work that uses the > library". The executable is therefore covered by this License. > Section 6 states terms for distribution of such executables. > > When a "work that uses the Library" uses material from a header file > that is part of the Library, the object code for the work may be a > derivative work of the Library even though the source code is not. > Whether this is true is especially significant if the work can be > linked without the Library, or if the work is itself a library. The > threshold for this to be true is not precisely defined by law. > > If such an object file uses only numerical parameters, data > structure layouts and accessors, and small macros and small inline > functions (ten lines or less in length), then the use of the object > file is unrestricted, regardless of whether it is legally a derivative > work. (Executables containing this object code plus portions of the > Library will still fall under Section 6.) > > Otherwise, if the work is a derivative of the Library, you may > distribute the object code for the work under the terms of Section 6. > Any executables containing that work also fall under Section 6, > whether or not they are linked directly with the Library itself. > > 6. As an exception to the Sections above, you may also combine or > link a "work that uses the Library" with the Library to produce a > work containing portions of the Library, and distribute that work > under terms of your choice, provided that the terms permit > modification of the work for the customer's own use and reverse > engineering for debugging such modifications. > > You must give prominent notice with each copy of the work that the > Library is used in it and that the Library and its use are covered by > this License. You must supply a copy of this License. If the work > during execution displays copyright notices, you must include the > copyright notice for the Library among them, as well as a reference > directing the user to the copy of this License. Also, you must do one > of these things: > > a) Accompany the work with the complete corresponding > machine-readable source code for the Library including whatever > changes were used in the work (which must be distributed under > Sections 1 and 2 above); and, if the work is an executable linked > with the Library, with the complete machine-readable "work that > uses the Library", as object code and/or source code, so that the > user can modify the Library and then relink to produce a modified > executable containing the modified Library. (It is understood > that the user who changes the contents of definitions files in the > Library will not necessarily be able to recompile the application > to use the modified definitions.) > > b) Use a suitable shared library mechanism for linking with the > Library. A suitable mechanism is one that (1) uses at run time a > copy of the library already present on the user's computer system, > rather than copying library functions into the executable, and (2) > will operate properly with a modified version of the library, if > the user installs one, as long as the modified version is > interface-compatible with the version that the work was made with. > > c) Accompany the work with a written offer, valid for at > least three years, to give the same user the materials > specified in Subsection 6a, above, for a charge no more > than the cost of performing this distribution. > > d) If distribution of the work is made by offering access to copy > from a designated place, offer equivalent access to copy the above > specified materials from the same place. > > e) Verify that the user has already received a copy of these > materials or that you have already sent this user a copy. > > For an executable, the required form of the "work that uses the > Library" must include any data and utility programs needed for > reproducing the executable from it. However, as a special exception, > the materials to be distributed need not include anything that is > normally distributed (in either source or binary form) with the major > components (compiler, kernel, and so on) of the operating system on > which the executable runs, unless that component itself accompanies > the executable. > > It may happen that this requirement contradicts the license > restrictions of other proprietary libraries that do not normally > accompany the operating system. Such a contradiction means you cannot > use both them and the Library together in an executable that you > distribute. > > 7. You may place library facilities that are a work based on the > Library side-by-side in a single library together with other library > facilities not covered by this License, and distribute such a combined > library, provided that the separate distribution of the work based on > the Library and of the other library facilities is otherwise > permitted, and provided that you do these two things: > > a) Accompany the combined library with a copy of the same work > based on the Library, uncombined with any other library > facilities. This must be distributed under the terms of the > Sections above. > > b) Give prominent notice with the combined library of the fact > that part of it is a work based on the Library, and explaining > where to find the accompanying uncombined form of the same work. > > 8. You may not copy, modify, sublicense, link with, or distribute > the Library except as expressly provided under this License. Any > attempt otherwise to copy, modify, sublicense, link with, or > distribute the Library is void, and will automatically terminate your > rights under this License. However, parties who have received copies, > or rights, from you under this License will not have their licenses > terminated so long as such parties remain in full compliance. > > 9. You are not required to accept this License, since you have not > signed it. However, nothing else grants you permission to modify or > distribute the Library or its derivative works. These actions are > prohibited by law if you do not accept this License. Therefore, by > modifying or distributing the Library (or any work based on the > Library), you indicate your acceptance of this License to do so, and > all its terms and conditions for copying, distributing or modifying > the Library or works based on it. > > 10. Each time you redistribute the Library (or any work based on the > Library), the recipient automatically receives a license from the > original licensor to copy, distribute, link with or modify the Library > subject to these terms and conditions. You may not impose any further > restrictions on the recipients' exercise of the rights granted herein. > You are not responsible for enforcing compliance by third parties with > this License. > > 11. If, as a consequence of a court judgment or allegation of patent > infringement or for any other reason (not limited to patent issues), > conditions are imposed on you (whether by court order, agreement or > otherwise) that contradict the conditions of this License, they do not > excuse you from the conditions of this License. If you cannot > distribute so as to satisfy simultaneously your obligations under this > License and any other pertinent obligations, then as a consequence you > may not distribute the Library at all. For example, if a patent > license would not permit royalty-free redistribution of the Library by > all those who receive copies directly or indirectly through you, then > the only way you could satisfy both it and this License would be to > refrain entirely from distribution of the Library. > > If any portion of this section is held invalid or unenforceable under any > particular circumstance, the balance of the section is intended to apply, > and the section as a whole is intended to apply in other circumstances. > > It is not the purpose of this section to induce you to infringe any > patents or other property right claims or to contest validity of any > such claims; this section has the sole purpose of protecting the > integrity of the free software distribution system which is > implemented by public license practices. Many people have made > generous contributions to the wide range of software distributed > through that system in reliance on consistent application of that > system; it is up to the author/donor to decide if he or she is willing > to distribute software through any other system and a licensee cannot > impose that choice. > > This section is intended to make thoroughly clear what is believed to > be a consequence of the rest of this License. > > 12. If the distribution and/or use of the Library is restricted in > certain countries either by patents or by copyrighted interfaces, the > original copyright holder who places the Library under this License may add > an explicit geographical distribution limitation excluding those countries, > so that distribution is permitted only in or among countries not thus > excluded. In such case, this License incorporates the limitation as if > written in the body of this License. > > 13. The Free Software Foundation may publish revised and/or new > versions of the Lesser General Public License from time to time. > Such new versions will be similar in spirit to the present version, > but may differ in detail to address new problems or concerns. > > Each version is given a distinguishing version number. If the Library > specifies a version number of this License which applies to it and > "any later version", you have the option of following the terms and > conditions either of that version or of any later version published by > the Free Software Foundation. If the Library does not specify a > license version number, you may choose any version ever published by > the Free Software Foundation. > > 14. If you wish to incorporate parts of the Library into other free > programs whose distribution conditions are incompatible with these, > write to the author to ask for permission. For software which is > copyrighted by the Free Software Foundation, write to the Free > Software Foundation; we sometimes make exceptions for this. Our > decision will be guided by the two goals of preserving the free status > of all derivatives of our free software and of promoting the sharing > and reuse of software generally. > > NO WARRANTY > > 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO > WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. > EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR > OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY > KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE > IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE > LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME > THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. > > 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN > WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY > AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU > FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR > CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE > LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING > RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A > FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF > SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH > DAMAGES. > > END OF TERMS AND CONDITIONS > > How to Apply These Terms to Your New Libraries > > If you develop a new library, and you want it to be of the greatest > possible use to the public, we recommend making it free software that > everyone can redistribute and change. You can do so by permitting > redistribution under these terms (or, alternatively, under the terms of the > ordinary General Public License). > > To apply these terms, attach the following notices to the library. It is > safest to attach them to the start of each source file to most effectively > convey the exclusion of warranty; and each file should have at least the > "copyright" line and a pointer to where the full notice is found. > > > Copyright (C) > > This library is free software; you can redistribute it and/or > modify it under the terms of the GNU Lesser General Public > License as published by the Free Software Foundation; either > version 2.1 of the License, or (at your option) any later version. > > This library is distributed in the hope that it will be useful, > but WITHOUT ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > Lesser General Public License for more details. > > You should have received a copy of the GNU Lesser General Public > License along with this library; if not, write to the Free Software > Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > > Also add information on how to contact you by electronic and paper mail. > > You should also get your employer (if you work as a programmer) or your > school, if any, to sign a "copyright disclaimer" for the library, if > necessary. Here is a sample; alter the names: > > Yoyodyne, Inc., hereby disclaims all copyright interest in the > library `Frob' (a library for tweaking knobs) written by James Random Hacker. > > , 1 April 1990 > Ty Coon, President of Vice > > That's all there is to it! > ------------------------ end of proposed license ------------------ > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From gjhanna at gmail.com Sun Mar 11 14:21:17 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Mon, 12 Mar 2007 09:21:17 +1300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hi Pavel, We are using RXTX under VMWare server in production, quite satisfactorily. We're using Red Hat Enterprise Server 4, and ... Whatever the "enterprise" VMWare product is. Regards, Greg H > Subject: [Rxtx] RXTX under VMWare server > To: rxtx at qbang.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. [ ... snip ... ] -- Pavel Parkhomenko -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070311/4cebb6f9/attachment-0085.html From gergg at cox.net Sun Mar 11 23:39:19 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 12 Mar 2007 00:39:19 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: <45F4E787.6050502@cox.net> Trent Jarvi wrote: > I can start going through the method interfaces later this week and giving > feedback. I would suggest that the JSR should not be too generic in > nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel > drivers that intend to look like EIA232 ports at the kernel driver level. > > some ideas: > > EIA232PortInterface > TermiosInterface > SerialPortInterface > > Something that differentiates this from thing like USB, I2C, ... which > should not have to deal with legacy serial claiming to be the comm api. I'm going to throw out a suggestion, which I am mostly serious about. What would happen if we took the appropriate bits of the J2ME connector API, and just used that as the new COMM API so that finally JSE and JME had a common foundation for these kinds of things? Gregg Wonderly From ra85551 at gmail.com Mon Mar 12 09:08:37 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Mon, 12 Mar 2007 18:08:37 +0300 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Should any application use the modem, HyperTerminal won't be able to talk to the modem. But it actually can send and receive AT comands, while my application cannot :-( > Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Thansk for the reference. I examined that example and found that there's no significant differences between my read/write implementation and that one, except that SimpleSnuV1 listens for serialEvent's, but not for sake of data retrieval, just for printing them out - I don't know why ;-) > Note that modems could care less what OS is on top. If you are trying to > match new lines to the OS and sending it to the mode for AT commands, > thats probably a mistake. I do send strings to serial port, not to OS, and do try to get answers back. If it is the mistake, what's the right way? > Also it would not hurt to print out the > individual bytes that you are sending to make sure they did not get > mangled along the path. Yeah, I am printing these bytes before doing write, but it means that I only see what I intend to write. How can I ensure that these bytes have gone out of the box and reached my modem? BTW, I found that my send/receive method is complex enough, so I've rewritten it. Please, see the following code and point any mistakes, because I don't know where can they remain yet. private static final int LARGE_TIMEOUT = 15000; private static final int SMALL_TIMEOUT = 500; ... private String sendATCommand(String command, String waitFor, boolean isRegex, boolean isAddCRLF) throws BeaconConnectException { byte[] buffer = new byte[512]; int offset; String result = ""; try { if (waitFor != null) { serialPort.enableReceiveTimeout(LARGE_TIMEOUT); } else { serialPort.enableReceiveTimeout(SMALL_TIMEOUT); } if (command != null) { OutputStream serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } offset = 0; InputStream serialInput = serialPort.getInputStream(); while (serialInput.available() != -1) { int bytesRead = serialInput.read(buffer, offset, buffer.length - offset); if (bytesRead == 0) { break; } offset += bytesRead; result = new String(buffer, 0, offset).trim(); if (waitFor != null) { System.out.println(result); if (isRegex && result.matches(waitFor) || result.contains(waitFor)) { break; } } } } catch (UnsupportedCommOperationException e) { throw new MyException("unsupported operation"); } catch (IOException e) { throw new MytException("serial I/O error"); } return result; } -- Pavel Parkhomenko From clayno at hotpop.com Thu Mar 15 02:47:34 2007 From: clayno at hotpop.com (Christopher Layno) Date: Thu, 15 Mar 2007 16:47:34 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi, we're using the latest release of rxtx (2.1-7r2) for our system that has two applications using the library. one application sends requests to the modem while the other simply checks the modem status. we deployed our system on a pentium machine with red hat linux 9.0 installed. now the problem arises when these two applications try to access the same modem at the same time. one of them will eventually have to throw the PortInUseException as shown below: 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException gnu.io.PortInUseException: root PID = 743 Program = java root PID = 743 Program = java root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) this was expected. what we didn't expect though was that if we repeat the scenario 5 times, always 5 times, the application would also throw a VM error: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4473CD21 Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so Current Java thread: at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) - locked <0x44cfd4c8> (a gnu.io.CommPortIdentifier) at ************ at ************ - locked <0x4476a468> (a **********) at ************ at ************ at ************ at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java :261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages( TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run( TCPTransport.java:701) at java.lang.Thread.run(Thread.java:534) note: i replaced some sensitive data with asterisks our team has looked everywhere on the internet, including your mail archives, for a solution to this problem but to no avail. i really hope you could help us out on this one. thanks in advance! best regards, chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070315/1936460a/attachment-0082.html From tjarvi at qbang.org Fri Mar 16 04:30:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 04:30:25 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: On Thu, 15 Mar 2007, Christopher Layno wrote: > hi, > > we're using the latest release of rxtx (2.1-7r2) for our system that has two > applications using the library. one application sends requests to the modem > while the other simply checks the modem status. we deployed our system on a > pentium machine with red hat linux 9.0 installed. > > now the problem arises when these two applications try to access the same > modem at the same time. one of them will eventually have to throw the > PortInUseException as shown below: > > 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException > gnu.io.PortInUseException: root PID = 743 Program = java root PID = > 743 Program = java root PID = 743 Program = ??? root PID = 743 Program > = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root > PID = 743 Program = ??? root PID = 743 Program = ??? > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > > this was expected. what we didn't expect though was that if we repeat the > scenario 5 times, always 5 times, the application would also throw a VM > error: > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x4473CD21 > Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 > Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so > > Current Java thread: > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) Hi Chris The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. The code is originally by Werner Almesberger. He gave us permission to use it in rxtx. You might look at what has changed since 1998 in his fuser application. Or you can just do like other OSs and do the following in fuserImp.c JNIEXPORT jstring JNICALL Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv *env, jobject obj, jstring arg) { return (*env)->NewStringUTF(env, "Unknown Application"); } It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. -- Trent Jarvi tjarvi at qang.org From Adrien.TOS at ingenico.com Fri Mar 16 05:11:12 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Fri, 16 Mar 2007 12:11:12 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903CBC312@frsnprexc1.usr.ingenico.loc> Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070316/972ab214/attachment-0081.html From joachim at buechse.de Fri Mar 16 05:13:24 2007 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 16 Mar 2007 12:13:24 +0100 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. From tjarvi at qbang.org Fri Mar 16 16:36:29 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 16:36:29 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Fri Mar 16 16:02:23 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 16 Mar 2007 18:02:23 -0400 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Not all platforms are Unix based. Also mixing native library usage and command-line calls is not an elegant solution, IMHO. One or the other, but not both. Andre On 16-Mar-07, at 07:13 , Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is > trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We >> only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From clayno at hotpop.com Sun Mar 18 22:17:28 2007 From: clayno at hotpop.com (Christopher Layno) Date: Mon, 19 Mar 2007 12:17:28 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi everyone, thank you so much for your replies. they were really helpful. anyway, before i sent the email, my team was already implementing a temporary solution by using joachim's suggestion. we invoked a lsof command from our java code although i share the same concern with trent and andre-john about portability issues. that's why i said it's just temporary. my superiors have yet to approve our bug fix. so my question now is this: is recompiling the rxtx source code the only way to solve this problem? because if it's the only solution, then i think my superiors would rather have a new release from the rxtx community itself that fixes this bug(?) rather than have my team recompile the source code. best regards, chris Trent Jarvi wrote: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. ... It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070318/237463b2/attachment-0078.html From tjarvi at qbang.org Mon Mar 19 16:20:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Mar 2007 16:20:52 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: Hi Chris I can compile a new version after the 21st if you do not feel comfortable doing so. Please send me an email reminder off-line then. On Mon, 19 Mar 2007, Christopher Layno wrote: > hi everyone, > > thank you so much for your replies. they were really helpful. > > anyway, before i sent the email, my team was already implementing a > temporary solution by using joachim's suggestion. > we invoked a lsof command from our java code although i share the same > concern with trent and andre-john about > portability issues. that's why i said it's just temporary. my superiors have > yet to approve our bug fix. > > so my question now is this: is recompiling the rxtx source code the only way > to solve this problem? because if it's the only > solution, then i think my superiors would rather have a new release from the > rxtx community itself that fixes this bug(?) > rather than have my team recompile the source code. > > best regards, > > chris > > Trent Jarvi wrote: > > Hi Joachim > > It would be nice to have that functionality but calling the program > introduces too many issues imho. Explaining to someone why rxtx invoked a > rogue lsof does not sound very interesting. > > On Fri, 16 Mar 2007, Joachim Buechse wrote: > > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: > > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. > > _______________________________________________ > Rxtx mailing list > Rxtx 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 Eric.Arseneau at sun.com Tue Mar 20 11:47:33 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Tue, 20 Mar 2007 10:47:33 -0700 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 Message-ID: <46001E35.9040608@sun.com> Anyone have any experience with RXTX working with JDK 6 on other platforms ? From mm at UDel.Edu Tue Mar 20 12:18:29 2007 From: mm at UDel.Edu (Mike Markowski) Date: Tue, 20 Mar 2007 14:18:29 -0400 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 In-Reply-To: <46001E35.9040608@sun.com> References: <46001E35.9040608@sun.com> Message-ID: <46002575.4000306@udel.edu> Eric Arseneau wrote: > Anyone have any experience with RXTX working with JDK 6 on other platforms ? I'm using 32 bit intel, gentoo linux, jdk6 with no problems. My applications only use a serial port, though, nothing on the parallel port. Mike From falko.guderian at gmx.de Wed Mar 21 08:17:35 2007 From: falko.guderian at gmx.de (Falko Guderian) Date: Wed, 21 Mar 2007 15:17:35 +0100 Subject: [Rxtx] RXTX binaries for SH4 Message-ID: <46013E7F.40102@gmx.de> Dear developers, I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no possiblities to compile the source code. Better, I'm not able to do this at the moment. Can you provide me with rxtxSerial.dll (SH4) in the rxtx-2.1-8-testing version? (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) The reason for the testing version is I need custom baud rates. Thanks for help. Kind regards, Falko Guderian From tjarvi at qbang.org Wed Mar 21 21:38:37 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Mar 2007 21:38:37 -0600 (MDT) Subject: [Rxtx] RXTX binaries for SH4 In-Reply-To: <46013E7F.40102@gmx.de> References: <46013E7F.40102@gmx.de> Message-ID: On Wed, 21 Mar 2007, Falko Guderian wrote: > Dear developers, > > I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no > possiblities to compile the source code. Better, I'm not able to do this > at the moment. Can you provide me with rxtxSerial.dll (SH4) in the > rxtx-2.1-8-testing version? > (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) > > The reason for the testing version is I need custom baud rates. > > Thanks for help. > Hi Falko WinCE binary format is not supported by gcc. That makes compiling limited to those familiar with the WinCE tools. I hope someone is able to provide them for you but it is not likely. WinCE has been compiled by others in the past but rxtx.org builds have never included WinCE. There is some information with the source concerning WinCE builds if you decide to do it. We can share your results too if you like. The source in the WinCE has never been updated for the custom baud rate. That would need changes from the main source I presume. If you look at the source, you will note that Michal Hobot created a mini fork in the source to handle wince but it has not been updated for 3 years. -- Trent Jarvi tjarvi at qbang.org From Adrien.TOS at ingenico.com Thu Mar 22 07:08:55 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Thu, 22 Mar 2007 14:08:55 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Hi everybody, Do you have any comments on this issue? Thanks! AT ________________________________ De : Adrien TOS Envoy? : vendredi 16 mars 2007 12:11 ? : 'rxtx at qbang.org' Cc : Adrien TOS Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070322/2306c538/attachment-0074.html From jeremy.reeve at zen.co.uk Mon Mar 19 07:36:04 2007 From: jeremy.reeve at zen.co.uk (Jeremy S. Reeve) Date: Mon, 19 Mar 2007 13:36:04 +0000 Subject: [Rxtx] rxtx failing to compile on Fedora Core 6 Message-ID: <1174311364.21865.6.camel@d9thc> When trying to compile latest source : rxtx-2.1-7r2 I get the following when running configure: ---------------- checking os.version 2.6.18-1.2200.fc5smp WARNING: configure is having a hard time determining which directory contains the file jni_md.h. Edit Makefile and fix the variable JAVANATINC to point to the correct directory. The following options are available: /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/ /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/linux/ If there are more than one option available the first was selected. WARNING: Kernel include files do not match the current kernel configure: creating ./config.status ------------------------ which seems OK checking the resultant Makefile but when attempting to build with gmake install I get the following output : ---------------------- 34 problems (34 warnings)/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/javah -classpath .:/home/jsr/rxtxsrc/rxtx-2.1-7r2:/home/jsr/rxtxsrc/rxtx-2.1-7r2/src:/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/ext/RXTXcomm.jar -d i686-pc-linux-gnu -jni `(for i in CommDriver CommPortEnumerator CommPortIdentifier CommPort CommPortOwnershipListener Configure I2C I2CPortEvent I2CPortEventListener I2CPort LPRPort NoSuchPortException ParallelPortEvent ParallelPortEventListener ParallelPort PortInUseException Raw RawPortEvent RawPortEventListener RawPort RS485 RS485PortEvent RS485PortEventListener RS485Port RXTXCommDriver RXTXPort RXTXVersion SerialPortEvent SerialPortEventListener SerialPort UnsupportedCommOperationException UnSupportedLoggerException Zystem;do \ if grep > /dev/null native.* \( /home/jsr/rxtxsrc/rxtx-2.1-7r2/./src/$i.java; then \ echo gnu.io.$i; \ fi; \ done)` i686-pc-linux-gnu/gnu_io_CommPortIdentifier.h: No such file or directory make: *** [/home/jsr/rxtxsrc/rxtx-2.1-7r2/gnu/io/CommDriver.class] Error 1 ------------------------ Any ideas or pointers? Regards, Jeremy From tjarvi at qbang.org Sat Mar 24 08:12:54 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 Mar 2007 08:12:54 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > From Adrien.TOS at ingenico.com Sat Mar 24 11:53:22 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Sat, 24 Mar 2007 18:53:22 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> I do not have the threshold setting enabled, I have explicitely disabled it with: port_.disableReceiveThreshold(); I have also run the same tests with the threshold setting enabled, but they also fail in the same way as described below. So it seems there is a problem with timeout handling on Win32? ________________________________ From: rxtx-bounces at qbang.org on behalf of Trent Jarvi Sent: Sat 3/24/2007 3:12 PM To: RXTX Developers and Users Subject: Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 8312 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20070324/f9e39c9b/attachment-0072.bin From greg.johnson at manchester.ac.uk Sun Mar 25 13:41:36 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Sun, 25 Mar 2007 21:41:36 +0200 Subject: [Rxtx] Mac intel weirdness Message-ID: Hi folks, I'm trying to get rxtx to work on my macbook pro with a USB-serial dongle on it. I am using the 2.1-8 code from the CVS (though it seems to report itself as 2.1-7: makes it difficult to prove to oneself that the changes have 'taken'! - line 4210 in SerialImp.c, line 40 in RXTXVersion.java) I am trying the 2.1-8 because of horrible lock problems in 2.1-7. However, the serialport closure code seems to be broken - it won't close because it believes the (previously opened!) port doesn't exist. Here is what I'm trying: 0. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "false" 1. Open a port Serialport serialport = (SerialPort) commportidentifier.open ("test",100); 2. Talk to a device ... 3. Close port serialport.close(); 4. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "true" - why is this? 5. Try to reopen port Serialport serialport2 = (SerialPort) commportidentifier.open("test", 100); throws PortInUseException. I've dug around a bit in the source, and it seems the SerialPort.close () should call the CommPortIdentifier.internalClosePort() (line 67 of CommPort.java). However, I crash out with the NoSuchPortException when getPortIdentifier is called. Which seems quite weird to me, seeing as it is called on this - which was create just beforehand. Does anyone know how to fix this? Cheers, greg From knute at frazmtn.com Sat Mar 24 10:32:38 2007 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 24 Mar 2007 09:32:38 -0700 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc>, Message-ID: <4604F036.17833.135298@knute.frazmtn.com> > >The behavior of timeout depends upon the setting of the threshold. Do you >have the threshold setting? > This is the same bug I reported last fall. There was a fellow that sent me an email asking if it had been fixed. I told him I didn't think so. He got somebody to write a fix for him but I have not been able to contact him again for the actual changes. The inaccurate timeout and the failure of blocking when no timeouts are set is a serious bug in my humble opinion and renders the software unusable for my applications. I'd really like to have an alternative to the Sun comm api but there just isn't one that I know of. -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Mar 26 16:17:00 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 26 Mar 2007 16:17:00 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> Message-ID: >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. From ra85551 at gmail.com Tue Mar 27 10:18:36 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Tue, 27 Mar 2007 20:18:36 +0400 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Ultimately I found a solution. At first, that wasn't actually the VMWare + WinXP + RXTX issue, that was WinXP + RXTX issue. But on pure XP it sometimes workes, sometimes not, while under VMWare I had never seen my snippet working at all. SimpleSnuV1.java would not help me, because there is only one line I missed, and SimpleSnuV1.java also doesn't contain it! It is as follows: serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_OUT | SerialPort.FLOWCONTROL_RTSCTS_IN); Thank you for your attention. -- Pavel Parkhomenko From griff at op.pl Wed Mar 28 01:28:19 2007 From: griff at op.pl (griff@op.pl) Date: Wed, 28 Mar 2007 09:28:19 +0200 Subject: [Rxtx] No blocking read on Windows. Message-ID: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/5d07d571/attachment-0069.html -------------- next part -------------- Hi, I have problem that InputStram.read() (SerialPort)?returns -1 instead blocking and waiting for data. I found that this problem was ?known in 2005 : ? >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > >> Hi Trent >> >> Thanks for the fast response. >> Here's a Q&D test program for the blocking read on windows that just >> attempts to read one byte, and prints the resulting byte. On my system it >> returns -1, where I expect that it keeps waiting for data. >> >This isn't happening on Linux so the bug is in src/termios.c.? I'll have >something this weekend to fix that. I'm using RXTX 2.1.7r2 and the problem still is here. Im using Windows XP and java 1.5 disableReciveTimeout() and disableReciveTreshhold() dont help. ? best regards ? Piotr Zielniok From Adrien.TOS at ingenico.com Wed Mar 28 01:40:46 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Wed, 28 Mar 2007 09:40:46 +0200 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903E88880@frsnprexc1.usr.ingenico.loc> Looking at the code, it seems there is no support for infinite timeout? And maybe the count++ < 20 condition is breaking out of the loop too early? The only condition to break out of the loop should either be the timeout has expired or the number of requested bytes has been received. -----Message d'origine----- De : rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] De la part de Trent Jarvi Envoy? : mardi 27 mars 2007 00:17 ? : RXTX Developers and Users Objet : Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From j.kenneth.gentle at acm.org Wed Mar 28 06:44:15 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 28 Mar 2007 08:44:15 -0400 Subject: [Rxtx] No blocking read on Windows. In-Reply-To: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> References: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> Message-ID: <200703281844.l2SIiITW028614@qbang.org> Just another "ME TOO!" - I'm seeing this problem on Windows XP, jre for windows XP/Embedded. I cranked receiveTimeout up to Integer.MAX_INT, but it doesn't seem to wait that long At 03:28 2007-03-28, you wrote: >Hi, >I have problem that InputStram.read() (SerialPort) returns -1 >instead blocking and waiting for data. I found that this problem >was known in 2005 : > > >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > > > >> Hi Trent > >> > >> Thanks for the fast response. > >> Here's a Q&D test program for the blocking read on windows that just > >> attempts to read one byte, and prints the resulting byte. On my system it > >> returns -1, where I expect that it keeps waiting for data. > >> > > >This isn't happening on Linux so the bug is in src/termios.c. I'll have > >something this weekend to fix that. > >I'm using RXTX 2.1.7r2 and the problem still is here. >Im using Windows XP and java 1.5 >disableReciveTimeout() and disableReciveTreshhold() dont help. > >best regards > >Piotr Zielniok > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From greg.johnson at manchester.ac.uk Wed Mar 28 14:43:29 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Wed, 28 Mar 2007 22:43:29 +0200 Subject: [Rxtx] Cannot close and reopen serial port Message-ID: <377F9765-7A9D-4CE9-9176-FFB63A2594F0@manchester.ac.uk> Dear all, It appears I cannot close a port properly: SerialPort serialport = portid.open("myprog",100); // do some stuff, all works fine serialport.close(); // all seems fine but... SerialPort sp2 = portid.open("myprog",100); throws PortInUseException. And when I dig into the rxtx code, I find in CommPort.java, in close(): CommPortIdentifier cp = CommPortIdentifier.getPortIdentifier(this); (line 64 or there abouts) but this throws a NoSuchPortException which is caught but ignored (line 74ish). Can anyone suggest how this could happen: a port that was valid, opened, and used, throws a NSPE when it comes to closing it? I'm pulling my (remaining) hair out over this one! Cheers, greg PS And thanks for RXTX - it's great to have! PPS (21.-7. winxp/osx both, java 1.5) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/c28852fc/attachment-0068.html From rxtx at vrijheidslaan.net Fri Mar 30 16:52:50 2007 From: rxtx at vrijheidslaan.net (Rob) Date: Fri, 30 Mar 2007 22:52:50 -0000 Subject: [Rxtx] Cvs Question Message-ID: <61896.80.126.150.87.1175295162.squirrel@webmail.provalue.nl> Hi There, Im trying to get the latest version to work on mac osx. Problem is that i can't checkout version 2.1.8. Probably my fault but can some one please give me the alternative commands for: [user at myhost]$ export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot [user at myhost]$ cvs login Thanx, Rob From ra85551 at gmail.com Thu Mar 1 03:47:06 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Thu, 1 Mar 2007 13:47:06 +0300 Subject: [Rxtx] enableReceiveTimeout() issue Message-ID: Hello, world! I found a limitation of 16300 ms for CommPort's enableReceiveTimeout() method, while in original javax.comm docs there are no any references to that. Is that a bug or feature? I actually need longer timeouts sometimees. -- Pavel Parkhomenko From lyon at docjava.com Thu Mar 1 07:54:17 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 01 Mar 2007 09:54:17 -0500 Subject: [Rxtx] parametric singleton design pattern In-Reply-To: References: <22d55aea0702081207q5e7f6785l352d498d6f5f9fb1@mail.gmail.com> <22d55aea0702100034o3bcf42f3j1d1a6257029a67b0@mail.gmail.com> Message-ID: Hi All, I have been thinking about the use of a design pattern to cache resources that are consumed by processes. Toward that end, I have arrived at a parametric singleton design pattern, which I mentioned on this list some time ago. The idea has been published at: http://www.jot.fm/issues/issue_2007_03/column2 I can't help but think that there should be an API available for dealing with the tracking of serial port usage. Perhaps it is a kind of resource manager called the: SerialPortManager basic prototypes already exist in this vain. See, for example: http://www.ce.rit.edu/research/projects/2005_fall/rt_poolsystem/doc/PoolMon/SerialPortManager.html http://www.eventhelix.com/RealtimeMantra/PatternCatalog/serial_port_design_pattern.htm And others shown by a google search on "SerialPortManager" Cheers! - Doug From Eric.Arseneau at sun.com Thu Mar 1 10:15:03 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:15:03 -0800 Subject: [Rxtx] Any known Java 6 issues with RXTX 2.1-7r2 ? Message-ID: <45E70A17.1060206@sun.com> I just did a test on a recent build of Solaris 11 x86 and it seems that I can connect to my serial device fine when Java 5 is the default, but when Java 6 is the default, no go. Any information ? From Eric.Arseneau at sun.com Thu Mar 1 10:19:58 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:19:58 -0800 Subject: [Rxtx] Mac OS X and missing data Message-ID: <45E70B3E.7040908@sun.com> We have a device which is USB based but presents itself as a serial port to a machine. On my MacBook Pro I can get excellent throughput if I get my device to send data as quickly as possible. On the desktop side, if I do an type of disk IO to log the data I get, I end up with some missing data at some point. I hooked up a USB analyzer and did confirm that all the data is sent as expected to the desktop from the device. I found a work around for this, buffer the data in memory and only write the data out when I've received it all. However, when the same code and same device is attempted on a co-workers MacBook Pro (same hardware specs), I get errors and must slow down dramatically the device side's sending of data. Any ideas/recommendations on what I can do to get rid of this error ? From what I can tell, it seems that RXTX is not able to wake up to the interrupts coming in indicating data is ready, quickly enough, is there anything I can do ? From chinkaiw at hotmail.com Fri Mar 2 00:57:43 2007 From: chinkaiw at hotmail.com (Wang Chinkai) Date: Fri, 02 Mar 2007 07:57:43 +0000 Subject: [Rxtx] dynamic detect rs232 port Message-ID: Hi all I have a question about detecting rs232 port dynamicly. I have to aceess some port and detect rs232 port at the same time. Some usb device simulates rs232 port , and I can not know what the port name it gets until it connects,so I have to detect it dynamic,but I have to access another rs232 device at the same time. I found a problem. If I use CommPortIdentifier.getPortIdentifiers() to get new port list , and the other rs232 access function will not close port correctly. So , How can I solve it . Thanks. _________________________________________________________________ ?? 2GB ???? Windows Live Mail ????????????? http://ideas.live.com/programpage.aspx?versionid=5d21c51a-b161-4314-9b0e-4911fb2b2e6d From eu259473 at tele2.it Fri Mar 2 06:16:40 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 02 Mar 2007 14:16:40 +0100 Subject: [Rxtx] rxtx on HP tru 64 unix Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070302/706c7a70/attachment-0096.html From tjarvi at qbang.org Fri Mar 2 08:39:33 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 08:39:33 -0700 (MST) Subject: [Rxtx] rxtx on HP tru 64 unix In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, "Giuseppe Marchese" wrote: > Hi > > I try to install rxtx on hp tru 64 but make fails, > There are somebody that do the same and work. > > > Sorry for may english! > > Hi Giuseppe Could you provide a log of the failure? script ./configure make # use gnu make exit The information will be in the typescript created. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 2 19:56:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 19:56:52 -0700 (MST) Subject: [Rxtx] dynamic detect rs232 port In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, Wang Chinkai wrote: > Hi all > > I have a question about detecting rs232 port dynamicly. > > I have to aceess some port and detect rs232 port at the same time. > Some usb device simulates rs232 port , and I can not know > what the port name it gets until it connects,so I have to detect it > dynamic,but I have to access > another rs232 device at the same time. > > I found a problem. Hi Wang This is a known problem. The code is braindead there. In fact there needs to be events even in a rudamentary way when you add a usb dongle. I'm burried in tasks not far from rxtx but not in rxtx. I can't get to the problem but we would accept patches if you dig into it. [I'm getting to the license question earlier too; I don't have another 10%] -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Fri Mar 2 23:19:01 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 01:19:01 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Hi, Under ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable USB -> serial converter(using virtual com port drivers), with using example code pretty much straight out of http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port opens fine, enumerations all work, etc. My application calls for a large amount of data to be transferred in a short amount of time at 2,000,000 baud. My hardware sends approximately 15,232 bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL converter work fine, and the application works using C++. In C++, I do a hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); to open the port, and a boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); to read the port. The variable buffer fills with the 15238 bytes, and returns. If I do a resultz = is.read(cbuf,0,15238); in java with RXTX where is = new BufferedReader(new InputStreamReader(port.getInputStream())); and where resultz is an int, and cbuf is a char [] cbuf, resultz gets EXACTLY 3968 bytes the first time called. If I call it multiple times, I get roughly 11k total(less than what is sent), never more than the 3968 bytes per is.read() call. My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 bytes. I've played with inputbuffersize, receive threshold, receivetimeout, and so on. The FTDI virtual com port drivers that I'm using are rock solid, and have had zero problems with them using a variety of applications, some of my own, some professionally written, etc. No flow control is used anyplace, no RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. No exceptions are being thrown. What am I doing wrong, and what I can adjust to receive the full 15k bytes in one single read? Thanks! Keith From Eric.Arseneau at sun.com Fri Mar 2 23:32:07 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Fri, 02 Mar 2007 22:32:07 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <45E91667.20501@sun.com> This is the same type of thing that is happening to me on Mac OS X and does not seem to behave the same on different machines. I posted a day or two ago on this with subject "Mac OS X and missing data". Would love to hear if there is a solution to this :) From tjarvi at qbang.org Sat Mar 3 10:54:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 10:54:17 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > Hi, > > Under > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable > USB -> serial converter(using virtual com port drivers), with using example > code pretty much straight out of > http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port > opens fine, enumerations all work, etc. > > My application calls for a large amount of data to be transferred in a short > amount of time at 2,000,000 baud. My hardware sends approximately 15,232 > bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL > converter work fine, and the application works using C++. > > In C++, I do a > > hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, > OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); > > to open the port, and a > > boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); > > to read the port. > > The variable buffer fills with the 15238 bytes, and returns. > > If I do a > > resultz = is.read(cbuf,0,15238); in java with RXTX > > where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > > and where resultz is an int, and cbuf is a char [] cbuf, resultz gets > EXACTLY 3968 bytes the first time called. If I call it multiple times, I get > roughly 11k total(less than what is sent), never more than the 3968 bytes > per is.read() call. > > My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 > bytes. > > I've played with inputbuffersize, receive threshold, receivetimeout, and so > on. The FTDI virtual com port drivers that I'm using are rock solid, and > have had zero problems with them using a variety of applications, some of my > own, some professionally written, etc. No flow control is used anyplace, no > RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. > > No exceptions are being thrown. > > What am I doing wrong, and what I can adjust to receive the full 15k bytes > in one single read? > > Thanks! > Hi Keith I would expect a 20 meg application is going to have different behavior with the OS than a smaller application with respect to the kernel memory managment, schedualing, ... Something subtle could be causing problems. With respect to the recieve timeout and threshold, if you set the timeout to zero and the threshold to the size of data you expect, read should not return until it get that data. You may try with a stand alone application that tests just that with the C/C++ API. If the read is returning with less data when tested for short reads, you have found a bug in the device driver more than likely. The USB dongle vendor would probably be interested in knowing about this. As mentioned, these devices are getting very good; almost bug free. I suspect you found a bug though if you did use the threshold and timeout properly. The missing data is typical when not using flow control. When the OS buffering fills, the hardware will start dropping bytes. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:38:52 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:38:52 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> update: I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now instead of 3968. This makes sense. 128 bytes of overhead + 3968 bytes of data = 4096 transfer size 32 bytes of overhead + 992 bytes of data = 1024 transfer size. 1/4 the data = 1/4 the overhead. I rearranged my reading like so: resultz = is.read(cbuf,0,3968); resultz = is.read(cbuf,3968,3968); resultz = is.read(cbuf,7936,3968); while (!(is.ready())); // wait for ready resultz = is.read(cbuf,11904,3334); and this grabs 15,238 bytes total. BUT, I still have the quandry of the screwed up multi-bytes. I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. Approx 8% of the data. The bad bytes always seem to take the flavor of 0x2018, 0x2019, x2022, x2030, x201d. Are these maybe errors and I don't know what they enumerate to? I still can't believe some other layer isn't handling putting those bytes together all in one stream for me. Thanks Keith ----- Original Message ----- From: "Keith" To: "Bob Jacobsen" ; "RXTX Developers and Users" Sent: Saturday, March 03, 2007 11:26 AM Subject: Re: [Rxtx] is.read() only returning 3968 bytes > Bob, > > > Interesting numerical coincidence is that (max USB transfer) - (what > > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > > needed to transfer that much data. > > I was thinking along the same lines. I don't know USB well, but I do know > that those numbers were close enough to warrant investigating the > relationship between them. > > > I think what you're seeing is the internal buffering of the USB data > > stream. You'll need some form of higher-level buffering to smooth > > that out. > > Shouldn't the InputStreamReader() and BufferedReader() provide this type of > buffering? Isn't that the idea behind those? > > > All hypotheses need to be tested. In this case, a test would be to > > check for missing data. If this idea is right, you'll get _all_ the > > data, but you won't be missing characters. > > I did start looking at the data. -- I'm getting weird results. > > I tried this: > > loopzz = 0; > > for (looptwo = 0; looptwo < 100000; looptwo++) { > while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > > }} > > So I'm reading one character at a time. The good news is that loopzz is > exactly 15238 at the end of the routine, which is perfectly correct. I > picked looptwo value out of thin air. > > The weird results come in terms of the values, the data isn't correct at > least in one case. Look here: > > 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > > This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). > But the 0x89 was replaced by 0x2030. Why the heck would the returned value > be 0x2030?? Why is the returned byte completely out of range? Why the > multibyte return? > > From InputStream in the API: > > read > public abstract int read() > throws IOExceptionReads the next byte of data from the > input stream. The value byte is returned as an int in the range 0 to 255. If > no byte is available because the end of the stream has been reached, the > value -1 is returned. This method blocks until input data is available, the > end of the stream is detected, or an exception is thrown. > Value should be 0-255. > > > In my application time is really critical, reading 1 byte at a time is > probably not going to work. > > Thanks Eric & Bob for looking at this. > > Keith > From tjarvi at qbang.org Sat Mar 3 12:52:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 12:52:27 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > update: > > I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now > instead of 3968. > > This makes sense. > > 128 bytes of overhead + 3968 bytes of data = 4096 transfer size > 32 bytes of overhead + 992 bytes of data = 1024 transfer size. > > 1/4 the data = 1/4 the overhead. > > I rearranged my reading like so: > > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. > Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? > > I still can't believe some other layer isn't handling putting those bytes > together all in one stream for me. > The layer for this in Serial land is flow control. Software and hardware flow control prevent the overruns you observe. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:54:41 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:54:41 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <001a01c75dcd$c8802a70$6600a8c0@jbh757ktruws7g> Trent, Thanks for taking the time to reply. > I would expect a 20 meg application is going to have different behavior > with the OS than a smaller application with respect to the kernel memory > managment, schedualing, ... Something subtle could be causing problems. Well, at least I know the VCP drivers, the OS, etc can handle 2mbps reliably. Without hiccuping or dropping bytes. The C++ code works reliably without flow control. > The missing data is typical when not using flow control. When the OS > buffering fills, the hardware will start dropping bytes. I'm actually not getting MISSING data, I'm getting CORRUPTED data. If you look at my most recent post, I'm getting these bad bytes in place of the correct values: 0x2018, 0x2019, x2022, x2030, x201d. Why would is.read() return values not in the range of 0-255 ? Thanks. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 08:59:14 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 07:59:14 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: At 1:19 AM -0500 3/3/07, Keith wrote: >If I do a > >resultz = is.read(cbuf,0,15238); in java with RXTX > >where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > >and where resultz is an int, and cbuf is a char [] cbuf, resultz gets >EXACTLY 3968 bytes the first time called. If I call it multiple times, I get >roughly 11k total(less than what is sent), never more than the 3968 bytes >per is.read() call. > >My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 >bytes. Interesting numerical coincidence is that (max USB transfer) - (what you get) = 4096-3968 = 128 bytes is (almost) the size of the headers needed to transfer that much data. I think what you're seeing is the internal buffering of the USB data stream. You'll need some form of higher-level buffering to smooth that out. All hypotheses need to be tested. In this case, a test would be to check for missing data. If this idea is right, you'll get _all_ the data, but you won't be missing characters. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 09:26:14 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 11:26:14 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Bob, > Interesting numerical coincidence is that (max USB transfer) - (what > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > needed to transfer that much data. I was thinking along the same lines. I don't know USB well, but I do know that those numbers were close enough to warrant investigating the relationship between them. > I think what you're seeing is the internal buffering of the USB data > stream. You'll need some form of higher-level buffering to smooth > that out. Shouldn't the InputStreamReader() and BufferedReader() provide this type of buffering? Isn't that the idea behind those? > All hypotheses need to be tested. In this case, a test would be to > check for missing data. If this idea is right, you'll get _all_ the > data, but you won't be missing characters. I did start looking at the data. -- I'm getting weird results. I tried this: loopzz = 0; for (looptwo = 0; looptwo < 100000; looptwo++) { while (is.ready()) { cbuf[loopzz] = (char) is.read(); loopzz++; }} So I'm reading one character at a time. The good news is that loopzz is exactly 15238 at the end of the routine, which is perfectly correct. I picked looptwo value out of thin air. The weird results come in terms of the values, the data isn't correct at least in one case. Look here: 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). But the 0x89 was replaced by 0x2030. Why the heck would the returned value be 0x2030?? Why is the returned byte completely out of range? Why the multibyte return? >From InputStream in the API: read public abstract int read() throws IOExceptionReads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown. Value should be 0-255. In my application time is really critical, reading 1 byte at a time is probably not going to work. Thanks Eric & Bob for looking at this. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 14:44:50 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 13:44:50 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: Java's "char" type is Unicode. I think what you're seeing is a bug in the byte -> Unicode translation. 0x2018, 0x2019 are the curly open and close quotes. There used to be (and might still be) bugs in the conversion of these in a couple of libc versions. Some of the ASCII -> ISO and ISO -> ASCII routines were a little over-ambitious with respect to handling the open and close quotes, and tried to convert them to the "curly" form inappropriately. Try _not_ casting it to char. Bob At 11:26 AM -0500 3/3/07, Keith wrote: >Bob, > >> Interesting numerical coincidence is that (max USB transfer) - (what >> you get) = 4096-3968 = 128 bytes is (almost) the size of the headers >> needed to transfer that much data. > >I was thinking along the same lines. I don't know USB well, but I do know >that those numbers were close enough to warrant investigating the >relationship between them. > >> I think what you're seeing is the internal buffering of the USB data >> stream. You'll need some form of higher-level buffering to smooth >> that out. > >Shouldn't the InputStreamReader() and BufferedReader() provide this type of >buffering? Isn't that the idea behind those? > >> All hypotheses need to be tested. In this case, a test would be to >> check for missing data. If this idea is right, you'll get _all_ the >> data, but you won't be missing characters. > >I did start looking at the data. -- I'm getting weird results. > >I tried this: > >loopzz = 0; > >for (looptwo = 0; looptwo < 100000; looptwo++) { >while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > >}} > >So I'm reading one character at a time. The good news is that loopzz is >exactly 15238 at the end of the routine, which is perfectly correct. I >picked looptwo value out of thin air. > >The weird results come in terms of the values, the data isn't correct at >least in one case. Look here: > >0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > >This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). >But the 0x89 was replaced by 0x2030. Why the heck would the returned value >be 0x2030?? Why is the returned byte completely out of range? Why the >multibyte return? > >>From InputStream in the API: > >read >public abstract int read() > throws IOExceptionReads the next byte of data from the >input stream. The value byte is returned as an int in the range 0 to 255. If >no byte is available because the end of the stream has been reached, the >value -1 is returned. This method blocks until input data is available, the >end of the stream is detected, or an exception is thrown. >Value should be 0-255. > > >In my application time is really critical, reading 1 byte at a time is >probably not going to work. > >Thanks Eric & Bob for looking at this. > >Keith > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 15:10:11 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 17:10:11 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Bob said ..... > Java's "char" type is Unicode. I think what you're seeing is a bug > in the byte -> Unicode translation. Bob -- I think you hit the nail on the head. I was just coming to the same realization here. I knew that something funny was going on because the same bytes always got "corrupted." I'm pretty sure its in the InputStreamReader() functionality where the conversion junk is happening. Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. I don't know if simply changing the cast is going to work. Since the conversion is happening upstream (pun intended), I don't think my cast is doing this. Also I think the compiler forced me to use the cast. I'm still playing around, and I'll report back once I nail it down. Thanks!! Keith From tjarvi at qbang.org Sat Mar 3 15:59:46 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 15:59:46 -0700 (MST) Subject: [Rxtx] Win64 rxtx Testers? Message-ID: I have compiled win64 binaries of rxtx. Are there any users interested in testing them? If so, I'll look into putting them on the web site. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Mar 3 15:35:06 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 14:35:06 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: Because of this and similar problems, JMRI does all it's serial IO using +only+ byte values. It's a but of a pain, as Java wants to go to char and int types a little too aggressively, but it does solve the "uncontrolled conversions" problems. Bob At 5:10 PM -0500 3/3/07, Keith wrote: >Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > >Bob -- I think you hit the nail on the head. > >I was just coming to the same realization here. I knew that something funny >was going on because the same bytes always got "corrupted." > >I'm pretty sure its in the InputStreamReader() functionality where the >conversion junk is happening. > >Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > >I don't know if simply changing the cast is going to work. Since the >conversion is happening upstream (pun intended), I don't think my cast is >doing this. Also I think the compiler forced me to use the cast. -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mark at mdsh.com Sun Mar 4 11:01:33 2007 From: mark at mdsh.com (Mark Himsley) Date: Sun, 04 Mar 2007 18:01:33 +0000 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: <5C01AC72C200388815C04982@bedroom.mdsh.local> On 03 March 2007 14:38 -0500 Keith wrote: > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT > consistent. Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? It looks like you need to use DataInputStream and DataOutputStream. -- Mark Himsley From tjarvi at qbang.org Sun Mar 4 11:35:08 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 11:35:08 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" > > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > > * Line #21 - Not sure if you need a (TM) mark for > the term "Sun" > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > OK. I'm going through this today. Some groups ask if rxtx could be under their license also. I think this is a good example of why I resist multiple licenses and focus on why the current license may not be usable by them. The RXTX project is a convergence of hobby and commercial interests. I happen to do both right now. The problem with licensing is we have to stay on top of them as they change. Clearly, adding more licenses will not make this easier. I'm acting as the hobby person today. RXTX always favors the hobby people. But as we move forward, I'm going to need to bring this to lawyers at work and explain to them what is going on. Others here may have to do this also. I don't anticipate problems or unexpected changes. The goal is a consistant, comprehendable and usable license as close to what we have now as possible. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 14:52:10 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 14:52:10 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (1/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: I'm breaking this into two parts. I expect the second part will need more attention. Comments first, then the changed material below. On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > Thanks > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. OK. RXTX for consitent use. java should not be capitalized because it does not only mean Sun [TM] Java [TM]. An example of this not meaning Java is when people use RXTX with GCJ. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". There are not any contributors that are in all of RXTX yet but I did update the comment to try to reflect the current situation without making it a nightmare to maintain. I looked to see how the Linux kernel does it as a reference point. > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" The URL can be problematic. I have done so below with a time reference. GNU does not provide version information in their URLS. I picture this being a problem when the version 3 comes out. > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > This will be corrected when the copy is updated to the version linked below. ---------------- begin proposed material involved -------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. ----------------- end proposed material involved -------------------- I'll be looking at the linking issue again next. That should be all that remains other than including the 2.1 version. Let me know if you have problems with anything here. I do not want to dilute the material I post next with these housekeeping tasks. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 16:08:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 16:08:36 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: For those that are wondering what is going on here, this next bit is the meat of the changes. We agreed a long time ago to put this disclaimer in. We did a so so job. It was in rxtx 2.0, not well written, ... So some groups using rxtx that would like to ship rxtx so users don't need to download, install, go to the mail-list to find why it failed, ... Then their legal teams tell them section 5 paragraph 2 is a show stopper. That was never the intent. Now going through what remains... > and might need a (TM) suffix to make Sun happy. Added disclaimer at the ended 'all trademarks belong...' > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. OK. As you can see I was trying to adjust GNU text there for the LGPL. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. used dynamically linked terminology. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". I tried to address this more upfront with an intent statement. Let me know if you have problems with it. I also tried to make it a little more clear what was derived from the GNU solution by moving the link location closer to GNU's suggestion. > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > Thats the intent. Here is the combined fixes. Note that only the material in /*-- --*/ is being touched. The new GPL license is there but unmodified. ------------------------ begin proposed new license ------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. | | An executable that contains no derivative of any portion of RXTX, but | is designed to work with RXTX by being dynamically linked with it, | is considered a "work that uses the Library" subject to the terms and | conditions of the GNU Lesser General Public License. | | The following has been added to the RXTX License to remove | any confusion about linking to RXTX. We want to allow in part what | section 5, paragraph 2 of the LGPL does not permit in the special | case of linking over a controlled interface. The intent is to add a | Java Specification Request or standards body defined interface in the | future as another exception but one is not currently available. | | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface | | As a special exception, the copyright holders of RXTX give you | permission to link RXTX with independent modules that communicate with | RXTX solely through the Sun Microsytems CommAPI interface version 2, | regardless of the license terms of these independent modules, and to copy | and distribute the resulting combined work under terms of your choice, | provided that every copy of the combined work is accompanied by a complete | copy of the source code of RXTX (the version of RXTX used to produce the | combined work), being distributed under the terms of the GNU Lesser General | Public License plus this exception. An independent module is a | module which is not derived from or based on RXTX. | | Note that people who make modified versions of RXTX are not obligated | to grant this special exception for their modified versions; it is | their choice whether to do so. The GNU Lesser General Public License | gives permission to release a modified version without this exception; this | exception also makes it possible to release a modified version which | carries forward this exception. | | You should have received a copy of the GNU Lesser General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA | All trademarks belong to their respective owners. --------------------------------------------------------------------------*/ The original GNU Lesser General Public License Follows. GNU LESSER GENERAL PUBLIC LICENSE Version 2.1, February 1999 Copyright (C) 1991, 1999 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. [This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence the version number 2.1.] Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This license, the Lesser General Public License, applies to some specially designated software packages--typically libraries--of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below. When we speak of free software, we are referring to freedom of use, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish); that you receive source code or can get it if you want it; that you can change the software and use pieces of it in new free programs; and that you are informed that you can do these things. To protect your rights, we need to make restrictions that forbid distributors to deny you these rights or to ask you to surrender these rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library or if you modify it. For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights. We protect your rights with a two-step method: (1) we copyright the library, and (2) we offer you this license, which gives you legal permission to copy, distribute and/or modify the library. To protect each distributor, we want to make it very clear that there is no warranty for the free library. Also, if the library is modified by someone else and passed on, the recipients should know that what they have is not the original version, so that the original author's reputation will not be affected by problems that might be introduced by others. Finally, software patents pose a constant threat to the existence of any free program. We wish to make sure that a company cannot effectively restrict the users of a free program by obtaining a restrictive license from a patent holder. Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license. Most GNU software, including some libraries, is covered by the ordinary GNU General Public License. This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs. When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library. We call this license the "Lesser" General Public License because it does Less to protect the user's freedom than the ordinary General Public License. It also provides other free software developers Less of an advantage over competing non-free programs. These disadvantages are the reason we use the ordinary General Public License for many libraries. However, the Lesser license provides advantages in certain special circumstances. For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License. In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software. For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU operating system, as well as its variant, the GNU/Linux operating system. Although the Lesser General Public License is Less protective of the users' freedom, it does ensure that the user of a program that is linked with the Library has the freedom and the wherewithal to run that program using a modified version of the Library. The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, whereas the latter must be combined with the library in order to run. GNU LESSER GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License Agreement applies to any software library or other program which contains a notice placed by the copyright holder or other authorized party saying it may be distributed under the terms of this Lesser General Public License (also called "this License"). Each licensee is addressed as "you". A "library" means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables. The "Library", below, refers to any such software library or work which has been distributed under these terms. A "work based on the Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term "modification".) "Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library. Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does. 1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) The modified work must itself be a software library. b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change. c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License. d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful. (For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library. In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. 4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange. If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code. 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables. When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law. If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.) Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself. 6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications. You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things: a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.) b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. c) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution. d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place. e) Verify that the user has already received a copy of these materials or that you have already sent this user a copy. For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute. 7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things: a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above. b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work. 8. You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 9. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Library (or any work based on the Library), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Library or works based on it. 10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties with this License. 11. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply, and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 12. If the distribution and/or use of the Library is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Library under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 13. The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation. 14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Libraries If you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the ordinary General Public License). To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Also add information on how to contact you by electronic and paper mail. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the library, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the library `Frob' (a library for tweaking knobs) written by James Random Hacker. , 1 April 1990 Ty Coon, President of Vice That's all there is to it! ------------------------ end of proposed license ------------------ -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sun Mar 4 16:26:04 2007 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 04 Mar 2007 17:26:04 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <45EB558C.3010609@cox.net> Bob Jacobsen wrote: > Because of this and similar problems, JMRI does all it's serial IO > using +only+ byte values. It's a but of a pain, as Java wants to go > to char and int types a little too aggressively, but it does solve > the "uncontrolled conversions" problems. Anytime that you are reading bytes of data that is not printable, unicode text, in Java, you really need to stay away from the Readers. Use input stream only, or you will see unicode valued byte groups converted to unicode "char" values. Gregg Wonderly From joachim at buechse.de Mon Mar 5 04:23:48 2007 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 5 Mar 2007 12:23:48 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> The behaviour is exactly what you asked for in you code. is = new BufferedReader(new InputStreamReader(port.getInputStream())); Readers return Text (ie unicode chars) not bytes. You instantiate the InputStreamReader without saying which charset you want, which means "platform default". As this is on Windows, it will convert Windows characters to equivalent unicode characters. If you want to read bytes, read bytes not Text. Reading bytes is done with InputStream and BufferedInputStream. BTW: The InputStream and Reader methods that read arrays are not guarenteed to fill up the array. You always have to check what you really got, and advance your index accordingly. A typical "read up to 32k" method looks like this: InputStream is= ... // -- determine the max buffer size int len= is.available(); if (len == 0) { len= 32 * 1024; } // -- read all available data byte[] buffer= new byte[len]; int pos= 0; int read; do { read= is.read(buffer, pos, buffer.length - pos); pos= pos + read; } while (read != -1 && pos < buffer.length); Best regards, Joachim --- Joachim B?chse Phone: +41 44 500 2604 Buechse Consulting Hadlaubsteig 2 CH-8006 Z?rich On 03.03.2007, at 23:10, Keith wrote: > Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > > Bob -- I think you hit the nail on the head. > > I was just coming to the same realization here. I knew that > something funny > was going on because the same bytes always got "corrupted." > > I'm pretty sure its in the InputStreamReader() functionality where the > conversion junk is happening. > > Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > > I don't know if simply changing the cast is going to work. Since the > conversion is happening upstream (pun intended), I don't think my > cast is > doing this. Also I think the compiler forced me to use the cast. > > I'm still playing around, and I'll report back once I nail it down. > > Thanks!! > > Keith > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Mon Mar 5 07:25:46 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 05 Mar 2007 08:25:46 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> Message-ID: <45EC286A.8060608@cox.net> Joachim Buechse wrote: > BTW: The InputStream and Reader methods that read arrays are not > guarenteed to fill up the array. You always have to check what you > really got, and advance your index accordingly. A typical "read up to > 32k" method looks like this: > > InputStream is= ... > // -- determine the max buffer size > int len= is.available(); > if (len == 0) { > len= 32 * 1024; > } > // -- read all available data > byte[] buffer= new byte[len]; > int pos= 0; > int read; > do { > read= is.read(buffer, pos, buffer.length - pos); > pos= pos + read; > } while (read != -1 && pos < buffer.length); > My preferred structure is. byte arr[ len ]; int cnt; int off = 0; while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { off += cnt; } This keeps you from adding -1 to pos when the read returns -1. It also skips out when the read is 0 bytes which, is not a described EOF in InputStream java docs, but is a condition I want to be aware of. Gregg Wonderly From joachim at buechse.de Tue Mar 6 02:52:58 2007 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 6 Mar 2007 10:52:58 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <45EC286A.8060608@cox.net> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: The code I copied was from a file resource reader, it shouldn't really be applied to networking/external IO code. Mea culpa. However aborting when you get 0 from read is not always what you want either (you kind of indicated that already). Some unix java implementations will return 0 if the kernel read was aborted with EINTER, which is rarely the point where you want to abort your read - at least not without further checks. A "complete" solution always depends on the events you need to handle and the time the total read could take in reality. In some cases it's worth checking Thread.isInterrupted() in the loop, some code re-loops on 0 but only a limited number of times, some check a total timeout limit, etc... Best regards, Joachim On 05.03.2007, at 15:25, Gregg Wonderly wrote: > My preferred structure is. > > byte arr[ len ]; > int cnt; > int off = 0; > while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { > off += cnt; > } > > This keeps you from adding -1 to pos when the read returns -1. It > also skips > out when the read is 0 bytes which, is not a described EOF in > InputStream java > docs, but is a condition I want to be aware of. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Mar 6 14:47:44 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 Mar 2007 14:47:44 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: Just FYI, rxtx will usually not break out on EINTER. The code in the native library usually does something close to this: do { read(...) } while ( !done && errno==EINTR ); Obviously there is a little more involved but it will retry on EINTER if not done. On Tue, 6 Mar 2007, Joachim Buechse wrote: > The code I copied was from a file resource reader, it shouldn't > really be applied to networking/external IO code. Mea culpa. > > However aborting when you get 0 from read is not always what you want > either (you kind of indicated that already). Some unix java > implementations will return 0 if the kernel read was aborted with > EINTER, which is rarely the point where you want to abort your read - > at least not without further checks. A "complete" solution always > depends on the events you need to handle and the time the total read > could take in reality. In some cases it's worth checking > Thread.isInterrupted() in the loop, some code re-loops on 0 but only > a limited number of times, some check a total timeout limit, etc... > > Best regards, > Joachim > > On 05.03.2007, at 15:25, Gregg Wonderly wrote: >> My preferred structure is. >> >> byte arr[ len ]; >> int cnt; >> int off = 0; >> while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { >> off += cnt; >> } >> >> This keeps you from adding -1 to pos when the read returns -1. It >> also skips >> out when the read is 0 bytes which, is not a described EOF in >> InputStream java >> docs, but is a condition I want to be aware of. >> >> Gregg Wonderly >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 gjhanna at gmail.com Thu Mar 8 13:42:52 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Fri, 9 Mar 2007 09:42:52 +1300 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? Message-ID: I've just struck an issue using rxtx in a multi-threaded environment: If I have 3 threads trying to open *the same* comm-port I get a deadlock in CommPortIdentifier.open If I have just 2, it works fine - I get a PortInUseException which is nice and I can handle it. The 3 thread->deadlock thing is causing me issues. (Sample code below). This is from the java thread-dump Found one Java-level deadlock: ============================= "Thread-2": waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object ), which is held by "Thread-1" "Thread-1": waiting to lock monitor 0x0003e9cc (object 0x2450e108, a gnu.io.CommPortIdentifier), which is held by "Thread-2" Java stack information for the threads listed above: =================================================== "Thread-2": at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:329) - waiting to lock <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) "Thread-1": at java.lang.Object.wait(Native Method) - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) - locked <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) (Apart from this, rxtx is working fantastically for us). I'm thinking I'll have to implement some sort of locking mechanism that *doesn't* use java synchronization to prevent this situation. (Which doesn't sound like a good idea to me). Any ideas? Thanks, Greg Hanna ============= RXTXLockTest.java ======================================== import gnu.io.CommPort; import gnu.io.CommPortIdentifier; /** * @author Greg Hanna * Minimal code to create a deadlock with rxtx in multithreaded open */ public class RXTXLockTest { public static void main(String[] args) { try { CommPortIdentifier cpiCom1 = CommPortIdentifier.getPortIdentifier ("COM14"); OpenThread t1 = new OpenThread (" one ", cpiCom1); OpenThread t2 = new OpenThread (" two ", cpiCom1); OpenThread t3 = new OpenThread (" 003 ", cpiCom1); t1.start(); t2.start(); t3.start(); // comment this out and it runs with (expected) PortInUseException } catch (Exception e) { e.printStackTrace(); } } } class OpenThread extends Thread { String name; CommPortIdentifier cpi; CommPort cp; public OpenThread (String name, CommPortIdentifier cpi) { this.name = name; this.cpi = cpi; System.out.println (System.currentTimeMillis() + name + " thread created"); } public void run () { try { System.out.println (System.currentTimeMillis() + name + " opening"); cp = cpi.open(name, 2000); System.out.println (System.currentTimeMillis() + name + " opened - sleeping"); sleep (2000); // do the serial comms with the device. System.out.println (System.currentTimeMillis() + name + " slept - closing"); cp.close(); System.out.println (System.currentTimeMillis() + name + " closed - exiting"); } catch (Exception e) { System.out.println ("Error in thread: " + name ); e.printStackTrace(); } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070308/d9a163c5/attachment-0089.html From eu259473 at tele2.it Fri Mar 9 02:46:20 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 09 Mar 2007 10:46:20 +0100 Subject: [Rxtx] rxtx: tru64 unix make fails Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070309/3b654523/attachment-0089.html From lyon at docjava.com Fri Mar 9 03:58:32 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 Mar 2007 05:58:32 -0500 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi All, The deadlock issue is one that I have been thinking about for some time now. It seems to me that we need a resource manager that enables assignment to a known process. The one thing that seems important about serial ports is that two applications should not use the same serial port at the same time. When this happens, it throws an exception. OK. The exception is a response to a lock condition that arises from an unavailable resource. An abstract implementation (not born of native methods) might assign a serial port to an application, until the application releases it (or is forced to release it by some kill mechanism). Some resources (like a registry) can be reused. But others, like the serial port, cannot. In the case of the serial port, we would like, I think, to have the flyweight design pattern without sharing and with object assignment tracking. A means of breaking deadlock (like a leasing mechanism) seems very useful, to me. My guess is that we can serialize the state of the Parametric Singleton Pattern (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) into the Preferences of the System. Preferences.systemRoot() might help with that. When a resource is checked out, the lease time and owner are listed. A thread that does this can be killed, but applications outside of Java are problematic. There is a compelling problem here. It is not just serial ports. Sound cards, cameras, microphones, files, tape drives, etc. All are consumed resources that are assigned to an application (or user) and deprive other applications, or users, from use. What, if anything, should we do? At present we throw PortInUseExceptions. Is that it? Can we do better? OK, the port is in use. Now what? Do I have to be root to go remove lock files and kill applications? Is there a better way? Thanks! - Doug >I've just struck an issue using rxtx in a multi-threaded environment: > >If I have 3 threads trying to open *the same* >comm-port I get a deadlock in >CommPortIdentifier.open >If I have just 2, it works fine - I get a >PortInUseException which is nice and I can >handle it. > >The 3 thread->deadlock thing is causing me issues. >(Sample code below). > >This is from the java thread-dump > >Found one Java-level deadlock: >============================= >"Thread-2": > waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), > which is held by "Thread-1" >"Thread-1": > waiting to lock monitor 0x0003e9cc (object >0x2450e108, a gnu.io.CommPortIdentifier ), > which is held by "Thread-2" > >Java stack information for the threads listed above: >=================================================== >"Thread-2": > at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) > - waiting to lock <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) >"Thread-1": > at java.lang.Object.wait(Native Method) > - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) > - locked <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) > > >(Apart from this, rxtx is working fantastically for us). > >I'm thinking I'll have to implement some sort of >locking mechanism that *doesn't* use java >synchronization to prevent this situation. >(Which doesn't sound like a good idea to me). > >Any ideas? > >Thanks, > >Greg Hanna > >============= RXTXLockTest.java ======================================== > >import gnu.io.CommPort; >import gnu.io.CommPortIdentifier; > >/** > * @author Greg Hanna > * Minimal code to create a deadlock with rxtx in multithreaded open > */ >public class RXTXLockTest { > ? > ?public static void main(String[] args) { > ?try { > ?CommPortIdentifier cpiCom1 = >CommPortIdentifier.getPortIdentifier ("COM14"); > ?OpenThread t1 = new OpenThread (" one ", cpiCom1); > ?OpenThread t2 = new OpenThread (" two ", cpiCom1); > ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); > ?t1.start(); > ?t2.start(); > ?t3.start(); // comment this out >and it runs with (expected) PortInUseException > ?} catch (Exception e) { > ?e.printStackTrace(); > ?} > ?} >} > >class OpenThread extends Thread { > ?String name; > ?CommPortIdentifier cpi; > ?CommPort cp; > ?public OpenThread (String name, CommPortIdentifier cpi) { > ? this.name = name; > ?this.cpi = cpi; > ?System.out.println >(System.currentTimeMillis() + name + " thread >created"); > ?} > ?public void run () { > ?try { > ?System.out.println >(System.currentTimeMillis() + name + " opening"); > ?cp = cpi.open(name, 2000); > ?System.out.println >(System.currentTimeMillis() + name + " opened - >sleeping"); > ?sleep (2000); // do the serial comms with the device. > ?System.out.println >(System.currentTimeMillis() + name + " slept - >closing"); > ?cp.close(); > ?System.out.println >(System.currentTimeMillis() + name + " closed - >exiting"); > ?} catch (Exception e) { > System.out.println ("Error in thread: " + name ); > ?e.printStackTrace(); > ?} > ?} >} > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Mar 9 06:37:45 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 Mar 2007 06:37:45 -0700 (MST) Subject: [Rxtx] rxtx: tru64 unix make fails In-Reply-To: References: Message-ID: On Fri, 9 Mar 2007, "Giuseppe Marchese" wrote: > Sorry for delay. > ? > This is log for ./configure and make > error. > ? > thanks for attention > ? > Make: '%.java,$(TOP)/$(CLASSDEST)/%.class,$(wildcard $(SPATH)/*.java)': extra chars.? > Stop. > Hi Giuseppe You need to use GNU make with the Makefile. I suspect the tru64 make is not happy with those rules. > configure: exit 0 Looks like configure is fairly happy. From tjarvi at qbang.org Sat Mar 10 07:43:51 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 07:43:51 -0700 (MST) Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi Doug I have very little time to look into this further but what we could do is open up an rxtx 3 devel branch in which a proof of concept could be worked on. It could be the proof of concept for a JSR others including Sun could look at/work on or parts of it could be recycled in a JSR. I'm working very hard on rxtx right now but it does not show. I'm looking at win64, mac intel/ppc, usb bluetooth and usb serial dongles. Some are going to be more tested than others but they are all on the plate. I'll be pushing all the fixes upstream when they are done. So I'm very busy in 2.1 but we could open a new branch. On Fri, 9 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > The deadlock issue is one that I have been thinking about > for some time now. > It seems to me that we need a resource manager that enables assignment > to a known process. > > The one thing that seems important about serial > ports is that two applications should not use the > same serial port at the same time. When this > happens, it throws an exception. > OK. > > The exception is a response to a lock condition that > arises from an unavailable resource. > > An abstract implementation (not born of native methods) might > assign a serial port to an application, until the > application releases it (or is forced to release > it by some kill mechanism). > > Some resources (like a registry) can be reused. > But others, like the serial port, > cannot. > > In the case of the serial port, we would like, I think, to > have the flyweight design pattern > without sharing and with object assignment tracking. > A means of breaking deadlock (like a leasing > mechanism) seems very useful, to me. > > My guess is that we can serialize the state of the Parametric Singleton Pattern > (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) > into the Preferences of the System. Preferences.systemRoot() might help > with that. When a resource is checked out, the lease time and owner are > listed. A thread that does this can be killed, but applications outside of Java > are problematic. > > There is a compelling problem here. It is not just serial ports. > Sound cards, cameras, microphones, files, tape drives, etc. All are consumed > resources that are assigned to an application (or > user) and deprive other applications, > or users, from use. > > What, if anything, should we do? At present we throw PortInUseExceptions. > Is that it? > Can we do better? > OK, the port is in use. Now what? > Do I have to be root to go remove lock files and kill applications? > Is there a better way? > > Thanks! > - Doug > >> I've just struck an issue using rxtx in a multi-threaded environment: >> >> If I have 3 threads trying to open *the same* >> comm-port I get a deadlock in >> CommPortIdentifier.open >> If I have just 2, it works fine - I get a >> PortInUseException which is nice and I can >> handle it. >> >> The 3 thread->deadlock thing is causing me issues. >> (Sample code below). >> >> This is from the java thread-dump >> >> Found one Java-level deadlock: >> ============================= >> "Thread-2": >> waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), >> which is held by "Thread-1" >> "Thread-1": >> waiting to lock monitor 0x0003e9cc (object >> 0x2450e108, a gnu.io.CommPortIdentifier ), >> which is held by "Thread-2" >> >> Java stack information for the threads listed above: >> =================================================== >> "Thread-2": >> at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) >> - waiting to lock <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> "Thread-1": >> at java.lang.Object.wait(Native Method) >> - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) >> - locked <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> >> >> (Apart from this, rxtx is working fantastically for us). >> >> I'm thinking I'll have to implement some sort of >> locking mechanism that *doesn't* use java >> synchronization to prevent this situation. >> (Which doesn't sound like a good idea to me). >> >> Any ideas? >> >> Thanks, >> >> Greg Hanna >> >> ============= RXTXLockTest.java ======================================== >> >> import gnu.io.CommPort; >> import gnu.io.CommPortIdentifier; >> >> /** >> * @author Greg Hanna >> * Minimal code to create a deadlock with rxtx in multithreaded open >> */ >> public class RXTXLockTest { >> ? >> ?public static void main(String[] args) { >> ?try { >> ?CommPortIdentifier cpiCom1 = >> CommPortIdentifier.getPortIdentifier ("COM14"); >> ?OpenThread t1 = new OpenThread (" one ", cpiCom1); >> ?OpenThread t2 = new OpenThread (" two ", cpiCom1); >> ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); >> ?t1.start(); >> ?t2.start(); >> ?t3.start(); // comment this out >> and it runs with (expected) PortInUseException >> ?} catch (Exception e) { >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> class OpenThread extends Thread { >> ?String name; >> ?CommPortIdentifier cpi; >> ?CommPort cp; >> ?public OpenThread (String name, CommPortIdentifier cpi) { >> ? this.name = name; >> ?this.cpi = cpi; >> ?System.out.println >> (System.currentTimeMillis() + name + " thread >> created"); >> ?} >> ?public void run () { >> ?try { >> ?System.out.println >> (System.currentTimeMillis() + name + " opening"); >> ?cp = cpi.open(name, 2000); >> ?System.out.println >> (System.currentTimeMillis() + name + " opened - >> sleeping"); >> ?sleep (2000); // do the serial comms with the device. >> ?System.out.println >> (System.currentTimeMillis() + name + " slept - >> closing"); >> ?cp.close(); >> ?System.out.println >> (System.currentTimeMillis() + name + " closed - >> exiting"); >> ?} catch (Exception e) { >> System.out.println ("Error in thread: " + name ); >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 mm at UDel.Edu Sat Mar 10 14:48:32 2007 From: mm at UDel.Edu (Mike Markowski) Date: Sat, 10 Mar 2007 16:48:32 -0500 Subject: [Rxtx] rxtx and Sun's comm api Message-ID: <45F327B0.2060004@udel.edu> Hi all, I joined the list a few days ago and apologize for what is likely a frequently asked question, though I haven't yet found it anywhere. I learned about rxtx.org through the readme on Sun's version 2 of their comms api. They give recommendations in that readme regarding how a better comms api should be written. Is this the aim of rxtx.org? I wrote an app on my linux box using the Sun comms api (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the fact that only linux and Solaris are supported. So I'm glad to find rxtx.org and am just reading up on how make the conversion so Windows users will be able to run the program as well. At the same time I'm just curious if rxtx.org and Sun are both heading in the same direction. Thanks for any background or historical info. Feel free to point me to any www pages if my googling has just completely missed the target! Thanks again, Mike From tjarvi at qbang.org Sat Mar 10 15:35:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 15:35:25 -0700 (MST) Subject: [Rxtx] rxtx and Sun's comm api In-Reply-To: <45F327B0.2060004@udel.edu> References: <45F327B0.2060004@udel.edu> Message-ID: On Sat, 10 Mar 2007, Mike Markowski wrote: > Hi all, > > I joined the list a few days ago and apologize for what is likely a > frequently asked question, though I haven't yet found it anywhere. I > learned about rxtx.org through the readme on Sun's version 2 of their > comms api. They give recommendations in that readme regarding how a > better comms api should be written. Is this the aim of rxtx.org? > > I wrote an app on my linux box using the Sun comms api > (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the > fact that only linux and Solaris are supported. So I'm glad to find > rxtx.org and am just reading up on how make the conversion so Windows > users will be able to run the program as well. At the same time I'm > just curious if rxtx.org and Sun are both heading in the same direction. > > Thanks for any background or historical info. Feel free to point me to > any www pages if my googling has just completely missed the target! > I do not have any news (good or bad) concerning RXTX and Sun working together but perhaps others here do. The main goal of RXTX is to expose POSIX termios interfaces to java users. The future support of javax.comm is questionable. We do not have resources for everything. gnu.io (RXTX 2.1) will be supported going forward and functions the same as CommAPI 2.0. If you have control of the source code you are working with, I would not advise using CommAPI 2.0 javax.comm. We do support CommAPI 2.0 javax.comm for older applications but I do not think that will last much longer for practical reasons. The download interest in CommAPI 2.0 javax.comm support is becomming negligible on this end. There has been discussion of a JSR effort but I do not know of any status change since it was mentioned. One problem with a JSR is that even a light weight process is going to be difficult for RXTX at this time. Maybe that will change in the future but then again it may not. For now, we are just going forward 'as is' in rxtx 2.1 with package gnu.io while trying as a secondary effort to backport the changes to rxtx 2.0 for javax.comm support for users that do not have a choice. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Mar 11 07:19:40 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 11 Mar 2007 08:19:40 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: Hi All, I have been a proponent of a JSR that makes use of RXTX. I have executed the proper agreements with Sun. At this point we are in the: Early Draft Review of Draft Specifications Stage. The best thing to do is to enter the quiet period and create a specification. The question of exactly how we, as a group, want to approach this problem, remains open. Typically, we should have both a specification and a reference implementation. Thus, it would be to our best advantage to have a nice, stable, cross platform RXTX distro that adheres to the groups specification. Now, from a specification standpoint, my personal view on the matter is that we create a series of interfaces, with nice documentation (or at least javadoc). Is this a good idea? Should we have a pure interface specification for the communication API? There are several issues, in my mind, which still weigh on us. Hot-pluggable dongles, long discovery process on pop-up ports, lack of uniformity on device names, lack of uniformity on locking, a precise understanding of how the SerialPortResourceManager works (or even if we should have one). The more questions we answer in our reference implementation, the better our specification will get. RXTX is a good working prototype, but, I don't know if that is what we want to use for a specification. Here is what I have for a CommPortInterface: */ public interface CommPortInterface { /** * @return a string representation of this port. */ String toString(); /** * Gets the name of the communications port. This name should correspond to * something the user can identify, like the label on the hardware. * @return name of the port */ String getName(); /** * @return an input stream that can be used to read data from the * communications port. If the port doesn't support reading data, this * method returns null. *

* The blocking behaviour of this input stream depends on the threshold * and timeout values, as shown below for a read buffer size of n * bytes: * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ThresholdTimeoutBlocking behaviour
StateValueStateValue
disableddisabledblock until data is available
enabledm bytesdisabledblock until min(m, n) bytes are available
disabledenabledt msblock for t ms or until data is available
enabledm bytesenabledt msblock for t ms or until min(m, n) bytes are * available
* @throws java.io.IOException */ InputStream getInputStream() throws IOException; /** * @return an output stream that can be used to send data to the * communications port. If the port doesn't support sending data, this * method returns null. * @throws java.io.IOException */ OutputStream getOutputStream() throws IOException; /** * Closes this communications port. * All PortOwnershipListeners will be? * notified of this change of ownership. Further method calls on this? * object will throw IllegalStateException. Further calls on the? * associated InputStream or OutputStream will throw IOException. *

* Close does not block. Undelivered data is discarded. Blocked read and? * write operations are aborted if the underlying operating systems? * supports an IO abort mechanism. To await the delivery of undelivered? * data call OutputStream.flush() or OutputStream.close() before calling? * Port.close(). */ void close(); /** * Enables receive threshold. * When the specified threshold number of bytes are retrieved, read will * return immediately. * * @param thresh the number of bytes in the input buffer * @throws gnu.io.UnsupportedCommOperationException * if receive threshold is * not supported by the driver * @see #disableReceiveThreshold */ void enableReceiveThreshold(int thresh) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive threshold. * * @see #enableReceiveThreshold */ void disableReceiveThreshold(); /** * @return true if receive threshold is enabled. * * @see #enableReceiveThreshold */ boolean isReceiveThresholdEnabled(); /** * @return the receive threshold value. If receive threshold is diabled * or not supported, this value is meaningless. * * @see #enableReceiveThreshold */ int getReceiveThreshold(); /** * Enables receive timeout. * When the specified number of milliseconds have elapsed, read will * return immediately. * * @param rcvTimeout the number of milliseconds to block for * @throws gnu.io.UnsupportedCommOperationException * if receive timeout is * not supported by the driver * @see #disableReceiveTimeout */ void enableReceiveTimeout(int rcvTimeout) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive timeout. * * @see #enableReceiveTimeout */ void disableReceiveTimeout(); /** * @return true if receive timeout is enabled. * * @see #enableReceiveTimeout */ boolean isReceiveTimeoutEnabled(); /** * @return the receive timeout value. If receive timeout is diabled * or not supported, this value is meaningless. * * @see #enableReceiveTimeout */ int getReceiveTimeout(); /** * Enables receive framing. * The supplied byte value in the input suggests the end of the received * frame, and read returns immediately. Only the low 8 bits of the * supplied value are significant. * * @param framingByte the frame delimiter * @throws gnu.io.UnsupportedCommOperationException * if receive framing is * not supported by the driver * @see #disableReceiveFraming */ void enableReceiveFraming(int framingByte) throws UnsupportedCommOperationException; /** * Disables receive framing. * * @see #enableReceiveFraming */ void disableReceiveFraming(); /** * @return true if receive framing is enabled. * * @see #enableReceiveFraming */ boolean isReceiveFramingEnabled(); /** * @return true if receive framing byte. If receive framing is diabled * or not supported, this value is meaningless. * * @see #enableReceiveFraming */ int getReceiveFramingByte(); /** * Sets the input buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setInputBufferSize(int size); /** * @return the input buffer size. * The driver may choose not to report correct values. */ int getInputBufferSize(); /** * Sets the output buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setOutputBufferSize(int size); /** * @return the output buffer size. * The driver may choose not to report correct values. */ int getOutputBufferSize(); } What do you think of that? Note the wishy washy nature of the spec: The driver may choose to ignore this method. Is that good enough for us? Thanks! - Doug From ra85551 at gmail.com Sun Mar 11 08:44:45 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Sun, 11 Mar 2007 17:44:45 +0300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hello, world! I am writing application that communicates with modem via AT commands. My OS is Linux Kubuntu Feisty Herd, to ensure that my application will run properly under Windows XP I installed VMWare server. When I tried to send AT command and evaluate modem answer under WinXP @ VMWare server, I actually didn't receive anything. I think that VM settings are right, because I do can communicate with modem by using standard HyperTerminall as well as I can do on native Windows. So, why RXTX doesn't work under VM, but works under Linux and pure Windows XP (i tested it there) well? The send/receive method code follows. private String sendATCommand(String command, final String waitFor, final boolean isRegex, boolean isAddCRLF, long timeout) throws BeaconConnectException { final long POLL_PERIOD = 100; final int BUFFER_SIZE = 512; final byte[] buffer = new byte[BUFFER_SIZE]; final InputStream serialInput; final OutputStream serialOutput; try { serialInput = serialPort.getInputStream(); if (command != null) { serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } } catch (IOException e) { throw new MyException("serial I/O error"); } TimerTask task = new TimerTask() { int offset = 0; int bytesRead; public synchronized void run() { try { if (serialInput.available() > 0) { bytesRead = serialInput.read(buffer, offset, BUFFER_SIZE - offset); } else { return; } } catch (IOException e) { // do nothing - maybe next time we'll read something } offset += bytesRead; if (waitFor != null) { String temporary = new String(buffer, 0, offset).trim(); if (isRegex && temporary.matches(waitFor) || temporary.contains(waitFor)) { cancel(); notify(); } } } }; Timer timer = new Timer(); timer.schedule(task, POLL_PERIOD, POLL_PERIOD); synchronized (task) { try { task.wait(timeout); task.cancel(); } catch (InterruptedException e) { } } //Cut off leading and trailing CRs, LFs and zeroes String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); System.out.println(response); return response; } -- Pavel Parkhomenko From tjarvi at qbang.org Sun Mar 11 11:48:22 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:48:22 -0600 (MDT) Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: On Sun, 11 Mar 2007, Pavel Parkhomenko wrote: > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. > > private String sendATCommand(String command, final String waitFor, > final boolean isRegex, boolean isAddCRLF, long timeout) > throws BeaconConnectException > { > final long POLL_PERIOD = 100; > final int BUFFER_SIZE = 512; > final byte[] buffer = new byte[BUFFER_SIZE]; > final InputStream serialInput; > final OutputStream serialOutput; > try > { > serialInput = serialPort.getInputStream(); > if (command != null) > { > serialOutput = serialPort.getOutputStream(); > if (isAddCRLF) > { > command += "\r\n"; > } > System.out.println(command); > serialOutput.write(command.getBytes()); > } > } > catch (IOException e) > { > throw new MyException("serial I/O error"); > } > > TimerTask task = new TimerTask() > { > int offset = 0; > int bytesRead; > public synchronized void run() > { > try > { > if (serialInput.available() > 0) > { > bytesRead = serialInput.read(buffer, offset, > BUFFER_SIZE - offset); > } > else > { > return; > } > } > catch (IOException e) > { > // do nothing - maybe next time we'll read something > } > offset += bytesRead; > if (waitFor != null) > { > String temporary = new String(buffer, 0, offset).trim(); > if (isRegex && temporary.matches(waitFor) || > temporary.contains(waitFor)) > { > cancel(); > notify(); > } > } > } > }; > > Timer timer = new Timer(); > timer.schedule(task, POLL_PERIOD, POLL_PERIOD); > synchronized (task) { > try > { > task.wait(timeout); > task.cancel(); > } > catch (InterruptedException e) > { > } > } > //Cut off leading and trailing CRs, LFs and zeroes > String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); > System.out.println(response); > return response; > } > > > Hi Pavel VMWare should not be a problem. I've used it in the past - though not with a modem. Make sure nothing else is using the modem. Then look in the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an example that should work. Note that modems could care less what OS is on top. If you are trying to match new lines to the OS and sending it to the mode for AT commands, thats probably a mistake. Also it would not hurt to print out the individual bytes that you are sending to make sure they did not get mangled along the path. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 11:55:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:55:48 -0600 (MDT) Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: On Sun, 11 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > I have been a proponent of a JSR that makes > use of RXTX. I have executed the proper agreements with Sun. > > At this point we are in the: > Early Draft Review of Draft Specifications Stage. > > The best thing to do is to enter the quiet period and create > a specification. The question of exactly how we, as a group, > want to approach this problem, remains open. > > Typically, we should have both a specification and a reference > implementation. Thus, it would be to our best advantage to have > a nice, stable, cross platform RXTX distro that adheres to the > groups specification. > > Now, from a specification standpoint, my personal view on the matter is > that we create a series of interfaces, with nice documentation (or at least > javadoc). > > Is this a good idea? Should we have a pure interface specification for > the communication API? > > There are several issues, in my mind, which still weigh on us. > Hot-pluggable dongles, long discovery process on pop-up ports, > lack of uniformity on device names, lack of uniformity on locking, > a precise understanding of how the SerialPortResourceManager > works (or even if we should have one). > > The more questions we answer in our reference implementation, the > better our specification will get. RXTX is a good working prototype, > but, I don't know if that is what we want to use for a specification. > > Here is what I have for a CommPortInterface: > */ > public interface CommPortInterface { Hi Doug, I can start going through the method interfaces later this week and giving feedback. I would suggest that the JSR should not be too generic in nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel drivers that intend to look like EIA232 ports at the kernel driver level. some ideas: EIA232PortInterface TermiosInterface SerialPortInterface Something that differentiates this from thing like USB, I2C, ... which should not have to deal with legacy serial claiming to be the comm api. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 12:52:19 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 12:52:19 -0600 (MDT) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: No news is good news with these posts. I'll start the process of pinging legal a week from Monday on my end if nobody has objections to the proposal. I just want to make sure everyone has time to raise objections. Obviously, anyone can fork from a previous version if they don't like the new license. I suspect we can avoid that though. On Sun, 4 Mar 2007, Trent Jarvi wrote: > > For those that are wondering what is going on here, this > next bit is the meat of the changes. We agreed a long time > ago to put this disclaimer in. We did a so so job. It was > in rxtx 2.0, not well written, ... So some groups using > rxtx that would like to ship rxtx so users don't need to > download, install, go to the mail-list to find why it failed, > ... Then their legal teams tell them section 5 paragraph 2 > is a show stopper. > > That was never the intent. > > > Now going through what remains... > >> and might need a (TM) suffix to make Sun happy. > > Added disclaimer at the ended 'all trademarks belong...' > >> * Line #15ff - static vs. dynamic linking - you did >> not transcribe the text from the "controlled >> interface exception" when writing this text - and >> this was good so, because these terms originally >> refer to the GPL rather than the LGPL. I think though, >> that these 4 lines are the most important ones and >> should thus be really really clear. I hope that I >> meet your original intent with the following >> suggestions: >> 1.) Instead of "A program.." it would be better to >> say "An exectuable.." in order to be closer to >> the LGPL text. > > OK. As you can see I was trying to adjust GNU text there > for the LGPL. > >> 2.) It would be better to say .. "by being dynamically >> linked with it" to clearly indicate that dynamic >> linking is meant. The matter of compilation is >> already covered by the LGPL so mentioning it again >> just leads to confusion. > > used dynamically linked terminology. > >> 3.) It would be better to say .. "is considered a >> work that uses the library in contrast to section >> 5 of the LGPL, so the terms of the LGPL do not >> apply to the resulting executable". > > I tried to address this more upfront with an intent statement. > Let me know if you have problems with it. I also tried to > make it a little more clear what was derived from the GNU > solution by moving the link location closer to GNU's suggestion. > >> >> Note that LGPL section 5 says: ..."is called a >> "work that uses the Library". Such a work, in isolation, >> is not a derivative work of the Library, and therefore >> falls outside the scope of this License." >> The next paragraph of the LGPL is exactly the problematic >> one that I hope is clarified by the exception terms you >> give. >> > > Thats the intent. Here is the combined fixes. Note that only the > material in /*-- --*/ is being touched. The new GPL license is > there but unmodified. > > > ------------------------ begin proposed new license ------------------- > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Lesser General Public > | License as published by the Free Software Foundation; either > | version 2.1 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Lesser General Public License for more details. > | > | An executable that contains no derivative of any portion of RXTX, but > | is designed to work with RXTX by being dynamically linked with it, > | is considered a "work that uses the Library" subject to the terms and > | conditions of the GNU Lesser General Public License. > | > | The following has been added to the RXTX License to remove > | any confusion about linking to RXTX. We want to allow in part what > | section 5, paragraph 2 of the LGPL does not permit in the special > | case of linking over a controlled interface. The intent is to add a > | Java Specification Request or standards body defined interface in the > | future as another exception but one is not currently available. > | > | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface > | > | As a special exception, the copyright holders of RXTX give you > | permission to link RXTX with independent modules that communicate with > | RXTX solely through the Sun Microsytems CommAPI interface version 2, > | regardless of the license terms of these independent modules, and to copy > | and distribute the resulting combined work under terms of your choice, > | provided that every copy of the combined work is accompanied by a complete > | copy of the source code of RXTX (the version of RXTX used to produce the > | combined work), being distributed under the terms of the GNU Lesser General > | Public License plus this exception. An independent module is a > | module which is not derived from or based on RXTX. > | > | Note that people who make modified versions of RXTX are not obligated > | to grant this special exception for their modified versions; it is > | their choice whether to do so. The GNU Lesser General Public License > | gives permission to release a modified version without this exception; this > | exception also makes it possible to release a modified version which > | carries forward this exception. > | > | You should have received a copy of the GNU Lesser General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > | All trademarks belong to their respective owners. > --------------------------------------------------------------------------*/ > > The original GNU Lesser General Public License Follows. > > > GNU LESSER GENERAL PUBLIC LICENSE > Version 2.1, February 1999 > > Copyright (C) 1991, 1999 Free Software Foundation, Inc. > 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > Everyone is permitted to copy and distribute verbatim copies > of this license document, but changing it is not allowed. > > [This is the first released version of the Lesser GPL. It also counts > as the successor of the GNU Library Public License, version 2, hence > the version number 2.1.] > > Preamble > > The licenses for most software are designed to take away your > freedom to share and change it. By contrast, the GNU General Public > Licenses are intended to guarantee your freedom to share and change > free software--to make sure the software is free for all its users. > > This license, the Lesser General Public License, applies to some > specially designated software packages--typically libraries--of the > Free Software Foundation and other authors who decide to use it. You > can use it too, but we suggest you first think carefully about whether > this license or the ordinary General Public License is the better > strategy to use in any particular case, based on the explanations below. > > When we speak of free software, we are referring to freedom of use, > not price. Our General Public Licenses are designed to make sure that > you have the freedom to distribute copies of free software (and charge > for this service if you wish); that you receive source code or can get > it if you want it; that you can change the software and use pieces of > it in new free programs; and that you are informed that you can do > these things. > > To protect your rights, we need to make restrictions that forbid > distributors to deny you these rights or to ask you to surrender these > rights. These restrictions translate to certain responsibilities for > you if you distribute copies of the library or if you modify it. > > For example, if you distribute copies of the library, whether gratis > or for a fee, you must give the recipients all the rights that we gave > you. You must make sure that they, too, receive or can get the source > code. If you link other code with the library, you must provide > complete object files to the recipients, so that they can relink them > with the library after making changes to the library and recompiling > it. And you must show them these terms so they know their rights. > > We protect your rights with a two-step method: (1) we copyright the > library, and (2) we offer you this license, which gives you legal > permission to copy, distribute and/or modify the library. > > To protect each distributor, we want to make it very clear that > there is no warranty for the free library. Also, if the library is > modified by someone else and passed on, the recipients should know > that what they have is not the original version, so that the original > author's reputation will not be affected by problems that might be > introduced by others. > > Finally, software patents pose a constant threat to the existence of > any free program. We wish to make sure that a company cannot > effectively restrict the users of a free program by obtaining a > restrictive license from a patent holder. Therefore, we insist that > any patent license obtained for a version of the library must be > consistent with the full freedom of use specified in this license. > > Most GNU software, including some libraries, is covered by the > ordinary GNU General Public License. This license, the GNU Lesser > General Public License, applies to certain designated libraries, and > is quite different from the ordinary General Public License. We use > this license for certain libraries in order to permit linking those > libraries into non-free programs. > > When a program is linked with a library, whether statically or using > a shared library, the combination of the two is legally speaking a > combined work, a derivative of the original library. The ordinary > General Public License therefore permits such linking only if the > entire combination fits its criteria of freedom. The Lesser General > Public License permits more lax criteria for linking other code with > the library. > > We call this license the "Lesser" General Public License because it > does Less to protect the user's freedom than the ordinary General > Public License. It also provides other free software developers Less > of an advantage over competing non-free programs. These disadvantages > are the reason we use the ordinary General Public License for many > libraries. However, the Lesser license provides advantages in certain > special circumstances. > > For example, on rare occasions, there may be a special need to > encourage the widest possible use of a certain library, so that it becomes > a de-facto standard. To achieve this, non-free programs must be > allowed to use the library. A more frequent case is that a free > library does the same job as widely used non-free libraries. In this > case, there is little to gain by limiting the free library to free > software only, so we use the Lesser General Public License. > > In other cases, permission to use a particular library in non-free > programs enables a greater number of people to use a large body of > free software. For example, permission to use the GNU C Library in > non-free programs enables many more people to use the whole GNU > operating system, as well as its variant, the GNU/Linux operating > system. > > Although the Lesser General Public License is Less protective of the > users' freedom, it does ensure that the user of a program that is > linked with the Library has the freedom and the wherewithal to run > that program using a modified version of the Library. > > The precise terms and conditions for copying, distribution and > modification follow. Pay close attention to the difference between a > "work based on the library" and a "work that uses the library". The > former contains code derived from the library, whereas the latter must > be combined with the library in order to run. > > GNU LESSER GENERAL PUBLIC LICENSE > TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION > > 0. This License Agreement applies to any software library or other > program which contains a notice placed by the copyright holder or > other authorized party saying it may be distributed under the terms of > this Lesser General Public License (also called "this License"). > Each licensee is addressed as "you". > > A "library" means a collection of software functions and/or data > prepared so as to be conveniently linked with application programs > (which use some of those functions and data) to form executables. > > The "Library", below, refers to any such software library or work > which has been distributed under these terms. A "work based on the > Library" means either the Library or any derivative work under > copyright law: that is to say, a work containing the Library or a > portion of it, either verbatim or with modifications and/or translated > straightforwardly into another language. (Hereinafter, translation is > included without limitation in the term "modification".) > > "Source code" for a work means the preferred form of the work for > making modifications to it. For a library, complete source code means > all the source code for all modules it contains, plus any associated > interface definition files, plus the scripts used to control compilation > and installation of the library. > > Activities other than copying, distribution and modification are not > covered by this License; they are outside its scope. The act of > running a program using the Library is not restricted, and output from > such a program is covered only if its contents constitute a work based > on the Library (independent of the use of the Library in a tool for > writing it). Whether that is true depends on what the Library does > and what the program that uses the Library does. > > 1. You may copy and distribute verbatim copies of the Library's > complete source code as you receive it, in any medium, provided that > you conspicuously and appropriately publish on each copy an > appropriate copyright notice and disclaimer of warranty; keep intact > all the notices that refer to this License and to the absence of any > warranty; and distribute a copy of this License along with the > Library. > > You may charge a fee for the physical act of transferring a copy, > and you may at your option offer warranty protection in exchange for a > fee. > > 2. You may modify your copy or copies of the Library or any portion > of it, thus forming a work based on the Library, and copy and > distribute such modifications or work under the terms of Section 1 > above, provided that you also meet all of these conditions: > > a) The modified work must itself be a software library. > > b) You must cause the files modified to carry prominent notices > stating that you changed the files and the date of any change. > > c) You must cause the whole of the work to be licensed at no > charge to all third parties under the terms of this License. > > d) If a facility in the modified Library refers to a function or a > table of data to be supplied by an application program that uses > the facility, other than as an argument passed when the facility > is invoked, then you must make a good faith effort to ensure that, > in the event an application does not supply such function or > table, the facility still operates, and performs whatever part of > its purpose remains meaningful. > > (For example, a function in a library to compute square roots has > a purpose that is entirely well-defined independent of the > application. Therefore, Subsection 2d requires that any > application-supplied function or table used by this function must > be optional: if the application does not supply it, the square > root function must still compute square roots.) > > These requirements apply to the modified work as a whole. If > identifiable sections of that work are not derived from the Library, > and can be reasonably considered independent and separate works in > themselves, then this License, and its terms, do not apply to those > sections when you distribute them as separate works. But when you > distribute the same sections as part of a whole which is a work based > on the Library, the distribution of the whole must be on the terms of > this License, whose permissions for other licensees extend to the > entire whole, and thus to each and every part regardless of who wrote > it. > > Thus, it is not the intent of this section to claim rights or contest > your rights to work written entirely by you; rather, the intent is to > exercise the right to control the distribution of derivative or > collective works based on the Library. > > In addition, mere aggregation of another work not based on the Library > with the Library (or with a work based on the Library) on a volume of > a storage or distribution medium does not bring the other work under > the scope of this License. > > 3. You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. To do > this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version 2, > instead of to this License. (If a newer version than version 2 of the > ordinary GNU General Public License has appeared, then you can specify > that version instead if you wish.) Do not make any other change in > these notices. > > Once this change is made in a given copy, it is irreversible for > that copy, so the ordinary GNU General Public License applies to all > subsequent copies and derivative works made from that copy. > > This option is useful when you wish to copy part of the code of > the Library into a program that is not a library. > > 4. You may copy and distribute the Library (or a portion or > derivative of it, under Section 2) in object code or executable form > under the terms of Sections 1 and 2 above provided that you accompany > it with the complete corresponding machine-readable source code, which > must be distributed under the terms of Sections 1 and 2 above on a > medium customarily used for software interchange. > > If distribution of object code is made by offering access to copy > from a designated place, then offering equivalent access to copy the > source code from the same place satisfies the requirement to > distribute the source code, even though third parties are not > compelled to copy the source along with the object code. > > 5. A program that contains no derivative of any portion of the > Library, but is designed to work with the Library by being compiled or > linked with it, is called a "work that uses the Library". Such a > work, in isolation, is not a derivative work of the Library, and > therefore falls outside the scope of this License. > > However, linking a "work that uses the Library" with the Library > creates an executable that is a derivative of the Library (because it > contains portions of the Library), rather than a "work that uses the > library". The executable is therefore covered by this License. > Section 6 states terms for distribution of such executables. > > When a "work that uses the Library" uses material from a header file > that is part of the Library, the object code for the work may be a > derivative work of the Library even though the source code is not. > Whether this is true is especially significant if the work can be > linked without the Library, or if the work is itself a library. The > threshold for this to be true is not precisely defined by law. > > If such an object file uses only numerical parameters, data > structure layouts and accessors, and small macros and small inline > functions (ten lines or less in length), then the use of the object > file is unrestricted, regardless of whether it is legally a derivative > work. (Executables containing this object code plus portions of the > Library will still fall under Section 6.) > > Otherwise, if the work is a derivative of the Library, you may > distribute the object code for the work under the terms of Section 6. > Any executables containing that work also fall under Section 6, > whether or not they are linked directly with the Library itself. > > 6. As an exception to the Sections above, you may also combine or > link a "work that uses the Library" with the Library to produce a > work containing portions of the Library, and distribute that work > under terms of your choice, provided that the terms permit > modification of the work for the customer's own use and reverse > engineering for debugging such modifications. > > You must give prominent notice with each copy of the work that the > Library is used in it and that the Library and its use are covered by > this License. You must supply a copy of this License. If the work > during execution displays copyright notices, you must include the > copyright notice for the Library among them, as well as a reference > directing the user to the copy of this License. Also, you must do one > of these things: > > a) Accompany the work with the complete corresponding > machine-readable source code for the Library including whatever > changes were used in the work (which must be distributed under > Sections 1 and 2 above); and, if the work is an executable linked > with the Library, with the complete machine-readable "work that > uses the Library", as object code and/or source code, so that the > user can modify the Library and then relink to produce a modified > executable containing the modified Library. (It is understood > that the user who changes the contents of definitions files in the > Library will not necessarily be able to recompile the application > to use the modified definitions.) > > b) Use a suitable shared library mechanism for linking with the > Library. A suitable mechanism is one that (1) uses at run time a > copy of the library already present on the user's computer system, > rather than copying library functions into the executable, and (2) > will operate properly with a modified version of the library, if > the user installs one, as long as the modified version is > interface-compatible with the version that the work was made with. > > c) Accompany the work with a written offer, valid for at > least three years, to give the same user the materials > specified in Subsection 6a, above, for a charge no more > than the cost of performing this distribution. > > d) If distribution of the work is made by offering access to copy > from a designated place, offer equivalent access to copy the above > specified materials from the same place. > > e) Verify that the user has already received a copy of these > materials or that you have already sent this user a copy. > > For an executable, the required form of the "work that uses the > Library" must include any data and utility programs needed for > reproducing the executable from it. However, as a special exception, > the materials to be distributed need not include anything that is > normally distributed (in either source or binary form) with the major > components (compiler, kernel, and so on) of the operating system on > which the executable runs, unless that component itself accompanies > the executable. > > It may happen that this requirement contradicts the license > restrictions of other proprietary libraries that do not normally > accompany the operating system. Such a contradiction means you cannot > use both them and the Library together in an executable that you > distribute. > > 7. You may place library facilities that are a work based on the > Library side-by-side in a single library together with other library > facilities not covered by this License, and distribute such a combined > library, provided that the separate distribution of the work based on > the Library and of the other library facilities is otherwise > permitted, and provided that you do these two things: > > a) Accompany the combined library with a copy of the same work > based on the Library, uncombined with any other library > facilities. This must be distributed under the terms of the > Sections above. > > b) Give prominent notice with the combined library of the fact > that part of it is a work based on the Library, and explaining > where to find the accompanying uncombined form of the same work. > > 8. You may not copy, modify, sublicense, link with, or distribute > the Library except as expressly provided under this License. Any > attempt otherwise to copy, modify, sublicense, link with, or > distribute the Library is void, and will automatically terminate your > rights under this License. However, parties who have received copies, > or rights, from you under this License will not have their licenses > terminated so long as such parties remain in full compliance. > > 9. You are not required to accept this License, since you have not > signed it. However, nothing else grants you permission to modify or > distribute the Library or its derivative works. These actions are > prohibited by law if you do not accept this License. Therefore, by > modifying or distributing the Library (or any work based on the > Library), you indicate your acceptance of this License to do so, and > all its terms and conditions for copying, distributing or modifying > the Library or works based on it. > > 10. Each time you redistribute the Library (or any work based on the > Library), the recipient automatically receives a license from the > original licensor to copy, distribute, link with or modify the Library > subject to these terms and conditions. You may not impose any further > restrictions on the recipients' exercise of the rights granted herein. > You are not responsible for enforcing compliance by third parties with > this License. > > 11. If, as a consequence of a court judgment or allegation of patent > infringement or for any other reason (not limited to patent issues), > conditions are imposed on you (whether by court order, agreement or > otherwise) that contradict the conditions of this License, they do not > excuse you from the conditions of this License. If you cannot > distribute so as to satisfy simultaneously your obligations under this > License and any other pertinent obligations, then as a consequence you > may not distribute the Library at all. For example, if a patent > license would not permit royalty-free redistribution of the Library by > all those who receive copies directly or indirectly through you, then > the only way you could satisfy both it and this License would be to > refrain entirely from distribution of the Library. > > If any portion of this section is held invalid or unenforceable under any > particular circumstance, the balance of the section is intended to apply, > and the section as a whole is intended to apply in other circumstances. > > It is not the purpose of this section to induce you to infringe any > patents or other property right claims or to contest validity of any > such claims; this section has the sole purpose of protecting the > integrity of the free software distribution system which is > implemented by public license practices. Many people have made > generous contributions to the wide range of software distributed > through that system in reliance on consistent application of that > system; it is up to the author/donor to decide if he or she is willing > to distribute software through any other system and a licensee cannot > impose that choice. > > This section is intended to make thoroughly clear what is believed to > be a consequence of the rest of this License. > > 12. If the distribution and/or use of the Library is restricted in > certain countries either by patents or by copyrighted interfaces, the > original copyright holder who places the Library under this License may add > an explicit geographical distribution limitation excluding those countries, > so that distribution is permitted only in or among countries not thus > excluded. In such case, this License incorporates the limitation as if > written in the body of this License. > > 13. The Free Software Foundation may publish revised and/or new > versions of the Lesser General Public License from time to time. > Such new versions will be similar in spirit to the present version, > but may differ in detail to address new problems or concerns. > > Each version is given a distinguishing version number. If the Library > specifies a version number of this License which applies to it and > "any later version", you have the option of following the terms and > conditions either of that version or of any later version published by > the Free Software Foundation. If the Library does not specify a > license version number, you may choose any version ever published by > the Free Software Foundation. > > 14. If you wish to incorporate parts of the Library into other free > programs whose distribution conditions are incompatible with these, > write to the author to ask for permission. For software which is > copyrighted by the Free Software Foundation, write to the Free > Software Foundation; we sometimes make exceptions for this. Our > decision will be guided by the two goals of preserving the free status > of all derivatives of our free software and of promoting the sharing > and reuse of software generally. > > NO WARRANTY > > 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO > WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. > EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR > OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY > KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE > IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE > LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME > THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. > > 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN > WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY > AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU > FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR > CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE > LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING > RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A > FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF > SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH > DAMAGES. > > END OF TERMS AND CONDITIONS > > How to Apply These Terms to Your New Libraries > > If you develop a new library, and you want it to be of the greatest > possible use to the public, we recommend making it free software that > everyone can redistribute and change. You can do so by permitting > redistribution under these terms (or, alternatively, under the terms of the > ordinary General Public License). > > To apply these terms, attach the following notices to the library. It is > safest to attach them to the start of each source file to most effectively > convey the exclusion of warranty; and each file should have at least the > "copyright" line and a pointer to where the full notice is found. > > > Copyright (C) > > This library is free software; you can redistribute it and/or > modify it under the terms of the GNU Lesser General Public > License as published by the Free Software Foundation; either > version 2.1 of the License, or (at your option) any later version. > > This library is distributed in the hope that it will be useful, > but WITHOUT ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > Lesser General Public License for more details. > > You should have received a copy of the GNU Lesser General Public > License along with this library; if not, write to the Free Software > Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > > Also add information on how to contact you by electronic and paper mail. > > You should also get your employer (if you work as a programmer) or your > school, if any, to sign a "copyright disclaimer" for the library, if > necessary. Here is a sample; alter the names: > > Yoyodyne, Inc., hereby disclaims all copyright interest in the > library `Frob' (a library for tweaking knobs) written by James Random Hacker. > > , 1 April 1990 > Ty Coon, President of Vice > > That's all there is to it! > ------------------------ end of proposed license ------------------ > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From gjhanna at gmail.com Sun Mar 11 14:21:17 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Mon, 12 Mar 2007 09:21:17 +1300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hi Pavel, We are using RXTX under VMWare server in production, quite satisfactorily. We're using Red Hat Enterprise Server 4, and ... Whatever the "enterprise" VMWare product is. Regards, Greg H > Subject: [Rxtx] RXTX under VMWare server > To: rxtx at qbang.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. [ ... snip ... ] -- Pavel Parkhomenko -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070311/4cebb6f9/attachment-0086.html From gergg at cox.net Sun Mar 11 23:39:19 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 12 Mar 2007 00:39:19 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: <45F4E787.6050502@cox.net> Trent Jarvi wrote: > I can start going through the method interfaces later this week and giving > feedback. I would suggest that the JSR should not be too generic in > nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel > drivers that intend to look like EIA232 ports at the kernel driver level. > > some ideas: > > EIA232PortInterface > TermiosInterface > SerialPortInterface > > Something that differentiates this from thing like USB, I2C, ... which > should not have to deal with legacy serial claiming to be the comm api. I'm going to throw out a suggestion, which I am mostly serious about. What would happen if we took the appropriate bits of the J2ME connector API, and just used that as the new COMM API so that finally JSE and JME had a common foundation for these kinds of things? Gregg Wonderly From ra85551 at gmail.com Mon Mar 12 09:08:37 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Mon, 12 Mar 2007 18:08:37 +0300 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Should any application use the modem, HyperTerminal won't be able to talk to the modem. But it actually can send and receive AT comands, while my application cannot :-( > Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Thansk for the reference. I examined that example and found that there's no significant differences between my read/write implementation and that one, except that SimpleSnuV1 listens for serialEvent's, but not for sake of data retrieval, just for printing them out - I don't know why ;-) > Note that modems could care less what OS is on top. If you are trying to > match new lines to the OS and sending it to the mode for AT commands, > thats probably a mistake. I do send strings to serial port, not to OS, and do try to get answers back. If it is the mistake, what's the right way? > Also it would not hurt to print out the > individual bytes that you are sending to make sure they did not get > mangled along the path. Yeah, I am printing these bytes before doing write, but it means that I only see what I intend to write. How can I ensure that these bytes have gone out of the box and reached my modem? BTW, I found that my send/receive method is complex enough, so I've rewritten it. Please, see the following code and point any mistakes, because I don't know where can they remain yet. private static final int LARGE_TIMEOUT = 15000; private static final int SMALL_TIMEOUT = 500; ... private String sendATCommand(String command, String waitFor, boolean isRegex, boolean isAddCRLF) throws BeaconConnectException { byte[] buffer = new byte[512]; int offset; String result = ""; try { if (waitFor != null) { serialPort.enableReceiveTimeout(LARGE_TIMEOUT); } else { serialPort.enableReceiveTimeout(SMALL_TIMEOUT); } if (command != null) { OutputStream serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } offset = 0; InputStream serialInput = serialPort.getInputStream(); while (serialInput.available() != -1) { int bytesRead = serialInput.read(buffer, offset, buffer.length - offset); if (bytesRead == 0) { break; } offset += bytesRead; result = new String(buffer, 0, offset).trim(); if (waitFor != null) { System.out.println(result); if (isRegex && result.matches(waitFor) || result.contains(waitFor)) { break; } } } } catch (UnsupportedCommOperationException e) { throw new MyException("unsupported operation"); } catch (IOException e) { throw new MytException("serial I/O error"); } return result; } -- Pavel Parkhomenko From clayno at hotpop.com Thu Mar 15 02:47:34 2007 From: clayno at hotpop.com (Christopher Layno) Date: Thu, 15 Mar 2007 16:47:34 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi, we're using the latest release of rxtx (2.1-7r2) for our system that has two applications using the library. one application sends requests to the modem while the other simply checks the modem status. we deployed our system on a pentium machine with red hat linux 9.0 installed. now the problem arises when these two applications try to access the same modem at the same time. one of them will eventually have to throw the PortInUseException as shown below: 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException gnu.io.PortInUseException: root PID = 743 Program = java root PID = 743 Program = java root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) this was expected. what we didn't expect though was that if we repeat the scenario 5 times, always 5 times, the application would also throw a VM error: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4473CD21 Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so Current Java thread: at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) - locked <0x44cfd4c8> (a gnu.io.CommPortIdentifier) at ************ at ************ - locked <0x4476a468> (a **********) at ************ at ************ at ************ at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java :261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages( TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run( TCPTransport.java:701) at java.lang.Thread.run(Thread.java:534) note: i replaced some sensitive data with asterisks our team has looked everywhere on the internet, including your mail archives, for a solution to this problem but to no avail. i really hope you could help us out on this one. thanks in advance! best regards, chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070315/1936460a/attachment-0083.html From tjarvi at qbang.org Fri Mar 16 04:30:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 04:30:25 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: On Thu, 15 Mar 2007, Christopher Layno wrote: > hi, > > we're using the latest release of rxtx (2.1-7r2) for our system that has two > applications using the library. one application sends requests to the modem > while the other simply checks the modem status. we deployed our system on a > pentium machine with red hat linux 9.0 installed. > > now the problem arises when these two applications try to access the same > modem at the same time. one of them will eventually have to throw the > PortInUseException as shown below: > > 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException > gnu.io.PortInUseException: root PID = 743 Program = java root PID = > 743 Program = java root PID = 743 Program = ??? root PID = 743 Program > = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root > PID = 743 Program = ??? root PID = 743 Program = ??? > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > > this was expected. what we didn't expect though was that if we repeat the > scenario 5 times, always 5 times, the application would also throw a VM > error: > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x4473CD21 > Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 > Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so > > Current Java thread: > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) Hi Chris The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. The code is originally by Werner Almesberger. He gave us permission to use it in rxtx. You might look at what has changed since 1998 in his fuser application. Or you can just do like other OSs and do the following in fuserImp.c JNIEXPORT jstring JNICALL Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv *env, jobject obj, jstring arg) { return (*env)->NewStringUTF(env, "Unknown Application"); } It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. -- Trent Jarvi tjarvi at qang.org From Adrien.TOS at ingenico.com Fri Mar 16 05:11:12 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Fri, 16 Mar 2007 12:11:12 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903CBC312@frsnprexc1.usr.ingenico.loc> Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070316/972ab214/attachment-0082.html From joachim at buechse.de Fri Mar 16 05:13:24 2007 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 16 Mar 2007 12:13:24 +0100 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. From tjarvi at qbang.org Fri Mar 16 16:36:29 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 16:36:29 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Fri Mar 16 16:02:23 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 16 Mar 2007 18:02:23 -0400 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Not all platforms are Unix based. Also mixing native library usage and command-line calls is not an elegant solution, IMHO. One or the other, but not both. Andre On 16-Mar-07, at 07:13 , Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is > trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We >> only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From clayno at hotpop.com Sun Mar 18 22:17:28 2007 From: clayno at hotpop.com (Christopher Layno) Date: Mon, 19 Mar 2007 12:17:28 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi everyone, thank you so much for your replies. they were really helpful. anyway, before i sent the email, my team was already implementing a temporary solution by using joachim's suggestion. we invoked a lsof command from our java code although i share the same concern with trent and andre-john about portability issues. that's why i said it's just temporary. my superiors have yet to approve our bug fix. so my question now is this: is recompiling the rxtx source code the only way to solve this problem? because if it's the only solution, then i think my superiors would rather have a new release from the rxtx community itself that fixes this bug(?) rather than have my team recompile the source code. best regards, chris Trent Jarvi wrote: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. ... It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070318/237463b2/attachment-0079.html From tjarvi at qbang.org Mon Mar 19 16:20:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Mar 2007 16:20:52 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: Hi Chris I can compile a new version after the 21st if you do not feel comfortable doing so. Please send me an email reminder off-line then. On Mon, 19 Mar 2007, Christopher Layno wrote: > hi everyone, > > thank you so much for your replies. they were really helpful. > > anyway, before i sent the email, my team was already implementing a > temporary solution by using joachim's suggestion. > we invoked a lsof command from our java code although i share the same > concern with trent and andre-john about > portability issues. that's why i said it's just temporary. my superiors have > yet to approve our bug fix. > > so my question now is this: is recompiling the rxtx source code the only way > to solve this problem? because if it's the only > solution, then i think my superiors would rather have a new release from the > rxtx community itself that fixes this bug(?) > rather than have my team recompile the source code. > > best regards, > > chris > > Trent Jarvi wrote: > > Hi Joachim > > It would be nice to have that functionality but calling the program > introduces too many issues imho. Explaining to someone why rxtx invoked a > rogue lsof does not sound very interesting. > > On Fri, 16 Mar 2007, Joachim Buechse wrote: > > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: > > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. > > _______________________________________________ > Rxtx mailing list > Rxtx 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 Eric.Arseneau at sun.com Tue Mar 20 11:47:33 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Tue, 20 Mar 2007 10:47:33 -0700 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 Message-ID: <46001E35.9040608@sun.com> Anyone have any experience with RXTX working with JDK 6 on other platforms ? From mm at UDel.Edu Tue Mar 20 12:18:29 2007 From: mm at UDel.Edu (Mike Markowski) Date: Tue, 20 Mar 2007 14:18:29 -0400 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 In-Reply-To: <46001E35.9040608@sun.com> References: <46001E35.9040608@sun.com> Message-ID: <46002575.4000306@udel.edu> Eric Arseneau wrote: > Anyone have any experience with RXTX working with JDK 6 on other platforms ? I'm using 32 bit intel, gentoo linux, jdk6 with no problems. My applications only use a serial port, though, nothing on the parallel port. Mike From falko.guderian at gmx.de Wed Mar 21 08:17:35 2007 From: falko.guderian at gmx.de (Falko Guderian) Date: Wed, 21 Mar 2007 15:17:35 +0100 Subject: [Rxtx] RXTX binaries for SH4 Message-ID: <46013E7F.40102@gmx.de> Dear developers, I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no possiblities to compile the source code. Better, I'm not able to do this at the moment. Can you provide me with rxtxSerial.dll (SH4) in the rxtx-2.1-8-testing version? (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) The reason for the testing version is I need custom baud rates. Thanks for help. Kind regards, Falko Guderian From tjarvi at qbang.org Wed Mar 21 21:38:37 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Mar 2007 21:38:37 -0600 (MDT) Subject: [Rxtx] RXTX binaries for SH4 In-Reply-To: <46013E7F.40102@gmx.de> References: <46013E7F.40102@gmx.de> Message-ID: On Wed, 21 Mar 2007, Falko Guderian wrote: > Dear developers, > > I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no > possiblities to compile the source code. Better, I'm not able to do this > at the moment. Can you provide me with rxtxSerial.dll (SH4) in the > rxtx-2.1-8-testing version? > (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) > > The reason for the testing version is I need custom baud rates. > > Thanks for help. > Hi Falko WinCE binary format is not supported by gcc. That makes compiling limited to those familiar with the WinCE tools. I hope someone is able to provide them for you but it is not likely. WinCE has been compiled by others in the past but rxtx.org builds have never included WinCE. There is some information with the source concerning WinCE builds if you decide to do it. We can share your results too if you like. The source in the WinCE has never been updated for the custom baud rate. That would need changes from the main source I presume. If you look at the source, you will note that Michal Hobot created a mini fork in the source to handle wince but it has not been updated for 3 years. -- Trent Jarvi tjarvi at qbang.org From Adrien.TOS at ingenico.com Thu Mar 22 07:08:55 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Thu, 22 Mar 2007 14:08:55 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Hi everybody, Do you have any comments on this issue? Thanks! AT ________________________________ De : Adrien TOS Envoy? : vendredi 16 mars 2007 12:11 ? : 'rxtx at qbang.org' Cc : Adrien TOS Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070322/2306c538/attachment-0075.html From jeremy.reeve at zen.co.uk Mon Mar 19 07:36:04 2007 From: jeremy.reeve at zen.co.uk (Jeremy S. Reeve) Date: Mon, 19 Mar 2007 13:36:04 +0000 Subject: [Rxtx] rxtx failing to compile on Fedora Core 6 Message-ID: <1174311364.21865.6.camel@d9thc> When trying to compile latest source : rxtx-2.1-7r2 I get the following when running configure: ---------------- checking os.version 2.6.18-1.2200.fc5smp WARNING: configure is having a hard time determining which directory contains the file jni_md.h. Edit Makefile and fix the variable JAVANATINC to point to the correct directory. The following options are available: /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/ /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/linux/ If there are more than one option available the first was selected. WARNING: Kernel include files do not match the current kernel configure: creating ./config.status ------------------------ which seems OK checking the resultant Makefile but when attempting to build with gmake install I get the following output : ---------------------- 34 problems (34 warnings)/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/javah -classpath .:/home/jsr/rxtxsrc/rxtx-2.1-7r2:/home/jsr/rxtxsrc/rxtx-2.1-7r2/src:/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/ext/RXTXcomm.jar -d i686-pc-linux-gnu -jni `(for i in CommDriver CommPortEnumerator CommPortIdentifier CommPort CommPortOwnershipListener Configure I2C I2CPortEvent I2CPortEventListener I2CPort LPRPort NoSuchPortException ParallelPortEvent ParallelPortEventListener ParallelPort PortInUseException Raw RawPortEvent RawPortEventListener RawPort RS485 RS485PortEvent RS485PortEventListener RS485Port RXTXCommDriver RXTXPort RXTXVersion SerialPortEvent SerialPortEventListener SerialPort UnsupportedCommOperationException UnSupportedLoggerException Zystem;do \ if grep > /dev/null native.* \( /home/jsr/rxtxsrc/rxtx-2.1-7r2/./src/$i.java; then \ echo gnu.io.$i; \ fi; \ done)` i686-pc-linux-gnu/gnu_io_CommPortIdentifier.h: No such file or directory make: *** [/home/jsr/rxtxsrc/rxtx-2.1-7r2/gnu/io/CommDriver.class] Error 1 ------------------------ Any ideas or pointers? Regards, Jeremy From tjarvi at qbang.org Sat Mar 24 08:12:54 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 Mar 2007 08:12:54 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > From Adrien.TOS at ingenico.com Sat Mar 24 11:53:22 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Sat, 24 Mar 2007 18:53:22 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> I do not have the threshold setting enabled, I have explicitely disabled it with: port_.disableReceiveThreshold(); I have also run the same tests with the threshold setting enabled, but they also fail in the same way as described below. So it seems there is a problem with timeout handling on Win32? ________________________________ From: rxtx-bounces at qbang.org on behalf of Trent Jarvi Sent: Sat 3/24/2007 3:12 PM To: RXTX Developers and Users Subject: Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 8312 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20070324/f9e39c9b/attachment-0073.bin From greg.johnson at manchester.ac.uk Sun Mar 25 13:41:36 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Sun, 25 Mar 2007 21:41:36 +0200 Subject: [Rxtx] Mac intel weirdness Message-ID: Hi folks, I'm trying to get rxtx to work on my macbook pro with a USB-serial dongle on it. I am using the 2.1-8 code from the CVS (though it seems to report itself as 2.1-7: makes it difficult to prove to oneself that the changes have 'taken'! - line 4210 in SerialImp.c, line 40 in RXTXVersion.java) I am trying the 2.1-8 because of horrible lock problems in 2.1-7. However, the serialport closure code seems to be broken - it won't close because it believes the (previously opened!) port doesn't exist. Here is what I'm trying: 0. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "false" 1. Open a port Serialport serialport = (SerialPort) commportidentifier.open ("test",100); 2. Talk to a device ... 3. Close port serialport.close(); 4. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "true" - why is this? 5. Try to reopen port Serialport serialport2 = (SerialPort) commportidentifier.open("test", 100); throws PortInUseException. I've dug around a bit in the source, and it seems the SerialPort.close () should call the CommPortIdentifier.internalClosePort() (line 67 of CommPort.java). However, I crash out with the NoSuchPortException when getPortIdentifier is called. Which seems quite weird to me, seeing as it is called on this - which was create just beforehand. Does anyone know how to fix this? Cheers, greg From knute at frazmtn.com Sat Mar 24 10:32:38 2007 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 24 Mar 2007 09:32:38 -0700 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc>, Message-ID: <4604F036.17833.135298@knute.frazmtn.com> > >The behavior of timeout depends upon the setting of the threshold. Do you >have the threshold setting? > This is the same bug I reported last fall. There was a fellow that sent me an email asking if it had been fixed. I told him I didn't think so. He got somebody to write a fix for him but I have not been able to contact him again for the actual changes. The inaccurate timeout and the failure of blocking when no timeouts are set is a serious bug in my humble opinion and renders the software unusable for my applications. I'd really like to have an alternative to the Sun comm api but there just isn't one that I know of. -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Mar 26 16:17:00 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 26 Mar 2007 16:17:00 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> Message-ID: >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. From ra85551 at gmail.com Tue Mar 27 10:18:36 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Tue, 27 Mar 2007 20:18:36 +0400 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Ultimately I found a solution. At first, that wasn't actually the VMWare + WinXP + RXTX issue, that was WinXP + RXTX issue. But on pure XP it sometimes workes, sometimes not, while under VMWare I had never seen my snippet working at all. SimpleSnuV1.java would not help me, because there is only one line I missed, and SimpleSnuV1.java also doesn't contain it! It is as follows: serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_OUT | SerialPort.FLOWCONTROL_RTSCTS_IN); Thank you for your attention. -- Pavel Parkhomenko From griff at op.pl Wed Mar 28 01:28:19 2007 From: griff at op.pl (griff@op.pl) Date: Wed, 28 Mar 2007 09:28:19 +0200 Subject: [Rxtx] No blocking read on Windows. Message-ID: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/5d07d571/attachment-0070.html -------------- next part -------------- Hi, I have problem that InputStram.read() (SerialPort)?returns -1 instead blocking and waiting for data. I found that this problem was ?known in 2005 : ? >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > >> Hi Trent >> >> Thanks for the fast response. >> Here's a Q&D test program for the blocking read on windows that just >> attempts to read one byte, and prints the resulting byte. On my system it >> returns -1, where I expect that it keeps waiting for data. >> >This isn't happening on Linux so the bug is in src/termios.c.? I'll have >something this weekend to fix that. I'm using RXTX 2.1.7r2 and the problem still is here. Im using Windows XP and java 1.5 disableReciveTimeout() and disableReciveTreshhold() dont help. ? best regards ? Piotr Zielniok From Adrien.TOS at ingenico.com Wed Mar 28 01:40:46 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Wed, 28 Mar 2007 09:40:46 +0200 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903E88880@frsnprexc1.usr.ingenico.loc> Looking at the code, it seems there is no support for infinite timeout? And maybe the count++ < 20 condition is breaking out of the loop too early? The only condition to break out of the loop should either be the timeout has expired or the number of requested bytes has been received. -----Message d'origine----- De : rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] De la part de Trent Jarvi Envoy? : mardi 27 mars 2007 00:17 ? : RXTX Developers and Users Objet : Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From j.kenneth.gentle at acm.org Wed Mar 28 06:44:15 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 28 Mar 2007 08:44:15 -0400 Subject: [Rxtx] No blocking read on Windows. In-Reply-To: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> References: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> Message-ID: <200703281844.l2SIiITW028614@qbang.org> Just another "ME TOO!" - I'm seeing this problem on Windows XP, jre for windows XP/Embedded. I cranked receiveTimeout up to Integer.MAX_INT, but it doesn't seem to wait that long At 03:28 2007-03-28, you wrote: >Hi, >I have problem that InputStram.read() (SerialPort) returns -1 >instead blocking and waiting for data. I found that this problem >was known in 2005 : > > >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > > > >> Hi Trent > >> > >> Thanks for the fast response. > >> Here's a Q&D test program for the blocking read on windows that just > >> attempts to read one byte, and prints the resulting byte. On my system it > >> returns -1, where I expect that it keeps waiting for data. > >> > > >This isn't happening on Linux so the bug is in src/termios.c. I'll have > >something this weekend to fix that. > >I'm using RXTX 2.1.7r2 and the problem still is here. >Im using Windows XP and java 1.5 >disableReciveTimeout() and disableReciveTreshhold() dont help. > >best regards > >Piotr Zielniok > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From greg.johnson at manchester.ac.uk Wed Mar 28 14:43:29 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Wed, 28 Mar 2007 22:43:29 +0200 Subject: [Rxtx] Cannot close and reopen serial port Message-ID: <377F9765-7A9D-4CE9-9176-FFB63A2594F0@manchester.ac.uk> Dear all, It appears I cannot close a port properly: SerialPort serialport = portid.open("myprog",100); // do some stuff, all works fine serialport.close(); // all seems fine but... SerialPort sp2 = portid.open("myprog",100); throws PortInUseException. And when I dig into the rxtx code, I find in CommPort.java, in close(): CommPortIdentifier cp = CommPortIdentifier.getPortIdentifier(this); (line 64 or there abouts) but this throws a NoSuchPortException which is caught but ignored (line 74ish). Can anyone suggest how this could happen: a port that was valid, opened, and used, throws a NSPE when it comes to closing it? I'm pulling my (remaining) hair out over this one! Cheers, greg PS And thanks for RXTX - it's great to have! PPS (21.-7. winxp/osx both, java 1.5) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/c28852fc/attachment-0069.html From rxtx at vrijheidslaan.net Fri Mar 30 16:52:50 2007 From: rxtx at vrijheidslaan.net (Rob) Date: Fri, 30 Mar 2007 22:52:50 -0000 Subject: [Rxtx] Cvs Question Message-ID: <61896.80.126.150.87.1175295162.squirrel@webmail.provalue.nl> Hi There, Im trying to get the latest version to work on mac osx. Problem is that i can't checkout version 2.1.8. Probably my fault but can some one please give me the alternative commands for: [user at myhost]$ export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot [user at myhost]$ cvs login Thanx, Rob From ra85551 at gmail.com Thu Mar 1 03:47:06 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Thu, 1 Mar 2007 13:47:06 +0300 Subject: [Rxtx] enableReceiveTimeout() issue Message-ID: Hello, world! I found a limitation of 16300 ms for CommPort's enableReceiveTimeout() method, while in original javax.comm docs there are no any references to that. Is that a bug or feature? I actually need longer timeouts sometimees. -- Pavel Parkhomenko From lyon at docjava.com Thu Mar 1 07:54:17 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 01 Mar 2007 09:54:17 -0500 Subject: [Rxtx] parametric singleton design pattern In-Reply-To: References: <22d55aea0702081207q5e7f6785l352d498d6f5f9fb1@mail.gmail.com> <22d55aea0702100034o3bcf42f3j1d1a6257029a67b0@mail.gmail.com> Message-ID: Hi All, I have been thinking about the use of a design pattern to cache resources that are consumed by processes. Toward that end, I have arrived at a parametric singleton design pattern, which I mentioned on this list some time ago. The idea has been published at: http://www.jot.fm/issues/issue_2007_03/column2 I can't help but think that there should be an API available for dealing with the tracking of serial port usage. Perhaps it is a kind of resource manager called the: SerialPortManager basic prototypes already exist in this vain. See, for example: http://www.ce.rit.edu/research/projects/2005_fall/rt_poolsystem/doc/PoolMon/SerialPortManager.html http://www.eventhelix.com/RealtimeMantra/PatternCatalog/serial_port_design_pattern.htm And others shown by a google search on "SerialPortManager" Cheers! - Doug From Eric.Arseneau at sun.com Thu Mar 1 10:15:03 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:15:03 -0800 Subject: [Rxtx] Any known Java 6 issues with RXTX 2.1-7r2 ? Message-ID: <45E70A17.1060206@sun.com> I just did a test on a recent build of Solaris 11 x86 and it seems that I can connect to my serial device fine when Java 5 is the default, but when Java 6 is the default, no go. Any information ? From Eric.Arseneau at sun.com Thu Mar 1 10:19:58 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:19:58 -0800 Subject: [Rxtx] Mac OS X and missing data Message-ID: <45E70B3E.7040908@sun.com> We have a device which is USB based but presents itself as a serial port to a machine. On my MacBook Pro I can get excellent throughput if I get my device to send data as quickly as possible. On the desktop side, if I do an type of disk IO to log the data I get, I end up with some missing data at some point. I hooked up a USB analyzer and did confirm that all the data is sent as expected to the desktop from the device. I found a work around for this, buffer the data in memory and only write the data out when I've received it all. However, when the same code and same device is attempted on a co-workers MacBook Pro (same hardware specs), I get errors and must slow down dramatically the device side's sending of data. Any ideas/recommendations on what I can do to get rid of this error ? From what I can tell, it seems that RXTX is not able to wake up to the interrupts coming in indicating data is ready, quickly enough, is there anything I can do ? From chinkaiw at hotmail.com Fri Mar 2 00:57:43 2007 From: chinkaiw at hotmail.com (Wang Chinkai) Date: Fri, 02 Mar 2007 07:57:43 +0000 Subject: [Rxtx] dynamic detect rs232 port Message-ID: Hi all I have a question about detecting rs232 port dynamicly. I have to aceess some port and detect rs232 port at the same time. Some usb device simulates rs232 port , and I can not know what the port name it gets until it connects,so I have to detect it dynamic,but I have to access another rs232 device at the same time. I found a problem. If I use CommPortIdentifier.getPortIdentifiers() to get new port list , and the other rs232 access function will not close port correctly. So , How can I solve it . Thanks. _________________________________________________________________ ?? 2GB ???? Windows Live Mail ????????????? http://ideas.live.com/programpage.aspx?versionid=5d21c51a-b161-4314-9b0e-4911fb2b2e6d From eu259473 at tele2.it Fri Mar 2 06:16:40 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 02 Mar 2007 14:16:40 +0100 Subject: [Rxtx] rxtx on HP tru 64 unix Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070302/706c7a70/attachment-0097.html From tjarvi at qbang.org Fri Mar 2 08:39:33 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 08:39:33 -0700 (MST) Subject: [Rxtx] rxtx on HP tru 64 unix In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, "Giuseppe Marchese" wrote: > Hi > > I try to install rxtx on hp tru 64 but make fails, > There are somebody that do the same and work. > > > Sorry for may english! > > Hi Giuseppe Could you provide a log of the failure? script ./configure make # use gnu make exit The information will be in the typescript created. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 2 19:56:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 19:56:52 -0700 (MST) Subject: [Rxtx] dynamic detect rs232 port In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, Wang Chinkai wrote: > Hi all > > I have a question about detecting rs232 port dynamicly. > > I have to aceess some port and detect rs232 port at the same time. > Some usb device simulates rs232 port , and I can not know > what the port name it gets until it connects,so I have to detect it > dynamic,but I have to access > another rs232 device at the same time. > > I found a problem. Hi Wang This is a known problem. The code is braindead there. In fact there needs to be events even in a rudamentary way when you add a usb dongle. I'm burried in tasks not far from rxtx but not in rxtx. I can't get to the problem but we would accept patches if you dig into it. [I'm getting to the license question earlier too; I don't have another 10%] -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Fri Mar 2 23:19:01 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 01:19:01 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Hi, Under ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable USB -> serial converter(using virtual com port drivers), with using example code pretty much straight out of http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port opens fine, enumerations all work, etc. My application calls for a large amount of data to be transferred in a short amount of time at 2,000,000 baud. My hardware sends approximately 15,232 bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL converter work fine, and the application works using C++. In C++, I do a hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); to open the port, and a boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); to read the port. The variable buffer fills with the 15238 bytes, and returns. If I do a resultz = is.read(cbuf,0,15238); in java with RXTX where is = new BufferedReader(new InputStreamReader(port.getInputStream())); and where resultz is an int, and cbuf is a char [] cbuf, resultz gets EXACTLY 3968 bytes the first time called. If I call it multiple times, I get roughly 11k total(less than what is sent), never more than the 3968 bytes per is.read() call. My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 bytes. I've played with inputbuffersize, receive threshold, receivetimeout, and so on. The FTDI virtual com port drivers that I'm using are rock solid, and have had zero problems with them using a variety of applications, some of my own, some professionally written, etc. No flow control is used anyplace, no RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. No exceptions are being thrown. What am I doing wrong, and what I can adjust to receive the full 15k bytes in one single read? Thanks! Keith From Eric.Arseneau at sun.com Fri Mar 2 23:32:07 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Fri, 02 Mar 2007 22:32:07 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <45E91667.20501@sun.com> This is the same type of thing that is happening to me on Mac OS X and does not seem to behave the same on different machines. I posted a day or two ago on this with subject "Mac OS X and missing data". Would love to hear if there is a solution to this :) From tjarvi at qbang.org Sat Mar 3 10:54:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 10:54:17 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > Hi, > > Under > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable > USB -> serial converter(using virtual com port drivers), with using example > code pretty much straight out of > http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port > opens fine, enumerations all work, etc. > > My application calls for a large amount of data to be transferred in a short > amount of time at 2,000,000 baud. My hardware sends approximately 15,232 > bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL > converter work fine, and the application works using C++. > > In C++, I do a > > hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, > OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); > > to open the port, and a > > boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); > > to read the port. > > The variable buffer fills with the 15238 bytes, and returns. > > If I do a > > resultz = is.read(cbuf,0,15238); in java with RXTX > > where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > > and where resultz is an int, and cbuf is a char [] cbuf, resultz gets > EXACTLY 3968 bytes the first time called. If I call it multiple times, I get > roughly 11k total(less than what is sent), never more than the 3968 bytes > per is.read() call. > > My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 > bytes. > > I've played with inputbuffersize, receive threshold, receivetimeout, and so > on. The FTDI virtual com port drivers that I'm using are rock solid, and > have had zero problems with them using a variety of applications, some of my > own, some professionally written, etc. No flow control is used anyplace, no > RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. > > No exceptions are being thrown. > > What am I doing wrong, and what I can adjust to receive the full 15k bytes > in one single read? > > Thanks! > Hi Keith I would expect a 20 meg application is going to have different behavior with the OS than a smaller application with respect to the kernel memory managment, schedualing, ... Something subtle could be causing problems. With respect to the recieve timeout and threshold, if you set the timeout to zero and the threshold to the size of data you expect, read should not return until it get that data. You may try with a stand alone application that tests just that with the C/C++ API. If the read is returning with less data when tested for short reads, you have found a bug in the device driver more than likely. The USB dongle vendor would probably be interested in knowing about this. As mentioned, these devices are getting very good; almost bug free. I suspect you found a bug though if you did use the threshold and timeout properly. The missing data is typical when not using flow control. When the OS buffering fills, the hardware will start dropping bytes. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:38:52 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:38:52 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> update: I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now instead of 3968. This makes sense. 128 bytes of overhead + 3968 bytes of data = 4096 transfer size 32 bytes of overhead + 992 bytes of data = 1024 transfer size. 1/4 the data = 1/4 the overhead. I rearranged my reading like so: resultz = is.read(cbuf,0,3968); resultz = is.read(cbuf,3968,3968); resultz = is.read(cbuf,7936,3968); while (!(is.ready())); // wait for ready resultz = is.read(cbuf,11904,3334); and this grabs 15,238 bytes total. BUT, I still have the quandry of the screwed up multi-bytes. I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. Approx 8% of the data. The bad bytes always seem to take the flavor of 0x2018, 0x2019, x2022, x2030, x201d. Are these maybe errors and I don't know what they enumerate to? I still can't believe some other layer isn't handling putting those bytes together all in one stream for me. Thanks Keith ----- Original Message ----- From: "Keith" To: "Bob Jacobsen" ; "RXTX Developers and Users" Sent: Saturday, March 03, 2007 11:26 AM Subject: Re: [Rxtx] is.read() only returning 3968 bytes > Bob, > > > Interesting numerical coincidence is that (max USB transfer) - (what > > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > > needed to transfer that much data. > > I was thinking along the same lines. I don't know USB well, but I do know > that those numbers were close enough to warrant investigating the > relationship between them. > > > I think what you're seeing is the internal buffering of the USB data > > stream. You'll need some form of higher-level buffering to smooth > > that out. > > Shouldn't the InputStreamReader() and BufferedReader() provide this type of > buffering? Isn't that the idea behind those? > > > All hypotheses need to be tested. In this case, a test would be to > > check for missing data. If this idea is right, you'll get _all_ the > > data, but you won't be missing characters. > > I did start looking at the data. -- I'm getting weird results. > > I tried this: > > loopzz = 0; > > for (looptwo = 0; looptwo < 100000; looptwo++) { > while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > > }} > > So I'm reading one character at a time. The good news is that loopzz is > exactly 15238 at the end of the routine, which is perfectly correct. I > picked looptwo value out of thin air. > > The weird results come in terms of the values, the data isn't correct at > least in one case. Look here: > > 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > > This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). > But the 0x89 was replaced by 0x2030. Why the heck would the returned value > be 0x2030?? Why is the returned byte completely out of range? Why the > multibyte return? > > From InputStream in the API: > > read > public abstract int read() > throws IOExceptionReads the next byte of data from the > input stream. The value byte is returned as an int in the range 0 to 255. If > no byte is available because the end of the stream has been reached, the > value -1 is returned. This method blocks until input data is available, the > end of the stream is detected, or an exception is thrown. > Value should be 0-255. > > > In my application time is really critical, reading 1 byte at a time is > probably not going to work. > > Thanks Eric & Bob for looking at this. > > Keith > From tjarvi at qbang.org Sat Mar 3 12:52:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 12:52:27 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > update: > > I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now > instead of 3968. > > This makes sense. > > 128 bytes of overhead + 3968 bytes of data = 4096 transfer size > 32 bytes of overhead + 992 bytes of data = 1024 transfer size. > > 1/4 the data = 1/4 the overhead. > > I rearranged my reading like so: > > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. > Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? > > I still can't believe some other layer isn't handling putting those bytes > together all in one stream for me. > The layer for this in Serial land is flow control. Software and hardware flow control prevent the overruns you observe. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:54:41 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:54:41 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <001a01c75dcd$c8802a70$6600a8c0@jbh757ktruws7g> Trent, Thanks for taking the time to reply. > I would expect a 20 meg application is going to have different behavior > with the OS than a smaller application with respect to the kernel memory > managment, schedualing, ... Something subtle could be causing problems. Well, at least I know the VCP drivers, the OS, etc can handle 2mbps reliably. Without hiccuping or dropping bytes. The C++ code works reliably without flow control. > The missing data is typical when not using flow control. When the OS > buffering fills, the hardware will start dropping bytes. I'm actually not getting MISSING data, I'm getting CORRUPTED data. If you look at my most recent post, I'm getting these bad bytes in place of the correct values: 0x2018, 0x2019, x2022, x2030, x201d. Why would is.read() return values not in the range of 0-255 ? Thanks. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 08:59:14 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 07:59:14 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: At 1:19 AM -0500 3/3/07, Keith wrote: >If I do a > >resultz = is.read(cbuf,0,15238); in java with RXTX > >where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > >and where resultz is an int, and cbuf is a char [] cbuf, resultz gets >EXACTLY 3968 bytes the first time called. If I call it multiple times, I get >roughly 11k total(less than what is sent), never more than the 3968 bytes >per is.read() call. > >My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 >bytes. Interesting numerical coincidence is that (max USB transfer) - (what you get) = 4096-3968 = 128 bytes is (almost) the size of the headers needed to transfer that much data. I think what you're seeing is the internal buffering of the USB data stream. You'll need some form of higher-level buffering to smooth that out. All hypotheses need to be tested. In this case, a test would be to check for missing data. If this idea is right, you'll get _all_ the data, but you won't be missing characters. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 09:26:14 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 11:26:14 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Bob, > Interesting numerical coincidence is that (max USB transfer) - (what > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > needed to transfer that much data. I was thinking along the same lines. I don't know USB well, but I do know that those numbers were close enough to warrant investigating the relationship between them. > I think what you're seeing is the internal buffering of the USB data > stream. You'll need some form of higher-level buffering to smooth > that out. Shouldn't the InputStreamReader() and BufferedReader() provide this type of buffering? Isn't that the idea behind those? > All hypotheses need to be tested. In this case, a test would be to > check for missing data. If this idea is right, you'll get _all_ the > data, but you won't be missing characters. I did start looking at the data. -- I'm getting weird results. I tried this: loopzz = 0; for (looptwo = 0; looptwo < 100000; looptwo++) { while (is.ready()) { cbuf[loopzz] = (char) is.read(); loopzz++; }} So I'm reading one character at a time. The good news is that loopzz is exactly 15238 at the end of the routine, which is perfectly correct. I picked looptwo value out of thin air. The weird results come in terms of the values, the data isn't correct at least in one case. Look here: 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). But the 0x89 was replaced by 0x2030. Why the heck would the returned value be 0x2030?? Why is the returned byte completely out of range? Why the multibyte return? >From InputStream in the API: read public abstract int read() throws IOExceptionReads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown. Value should be 0-255. In my application time is really critical, reading 1 byte at a time is probably not going to work. Thanks Eric & Bob for looking at this. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 14:44:50 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 13:44:50 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: Java's "char" type is Unicode. I think what you're seeing is a bug in the byte -> Unicode translation. 0x2018, 0x2019 are the curly open and close quotes. There used to be (and might still be) bugs in the conversion of these in a couple of libc versions. Some of the ASCII -> ISO and ISO -> ASCII routines were a little over-ambitious with respect to handling the open and close quotes, and tried to convert them to the "curly" form inappropriately. Try _not_ casting it to char. Bob At 11:26 AM -0500 3/3/07, Keith wrote: >Bob, > >> Interesting numerical coincidence is that (max USB transfer) - (what >> you get) = 4096-3968 = 128 bytes is (almost) the size of the headers >> needed to transfer that much data. > >I was thinking along the same lines. I don't know USB well, but I do know >that those numbers were close enough to warrant investigating the >relationship between them. > >> I think what you're seeing is the internal buffering of the USB data >> stream. You'll need some form of higher-level buffering to smooth >> that out. > >Shouldn't the InputStreamReader() and BufferedReader() provide this type of >buffering? Isn't that the idea behind those? > >> All hypotheses need to be tested. In this case, a test would be to >> check for missing data. If this idea is right, you'll get _all_ the >> data, but you won't be missing characters. > >I did start looking at the data. -- I'm getting weird results. > >I tried this: > >loopzz = 0; > >for (looptwo = 0; looptwo < 100000; looptwo++) { >while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > >}} > >So I'm reading one character at a time. The good news is that loopzz is >exactly 15238 at the end of the routine, which is perfectly correct. I >picked looptwo value out of thin air. > >The weird results come in terms of the values, the data isn't correct at >least in one case. Look here: > >0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > >This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). >But the 0x89 was replaced by 0x2030. Why the heck would the returned value >be 0x2030?? Why is the returned byte completely out of range? Why the >multibyte return? > >>From InputStream in the API: > >read >public abstract int read() > throws IOExceptionReads the next byte of data from the >input stream. The value byte is returned as an int in the range 0 to 255. If >no byte is available because the end of the stream has been reached, the >value -1 is returned. This method blocks until input data is available, the >end of the stream is detected, or an exception is thrown. >Value should be 0-255. > > >In my application time is really critical, reading 1 byte at a time is >probably not going to work. > >Thanks Eric & Bob for looking at this. > >Keith > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 15:10:11 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 17:10:11 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Bob said ..... > Java's "char" type is Unicode. I think what you're seeing is a bug > in the byte -> Unicode translation. Bob -- I think you hit the nail on the head. I was just coming to the same realization here. I knew that something funny was going on because the same bytes always got "corrupted." I'm pretty sure its in the InputStreamReader() functionality where the conversion junk is happening. Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. I don't know if simply changing the cast is going to work. Since the conversion is happening upstream (pun intended), I don't think my cast is doing this. Also I think the compiler forced me to use the cast. I'm still playing around, and I'll report back once I nail it down. Thanks!! Keith From tjarvi at qbang.org Sat Mar 3 15:59:46 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 15:59:46 -0700 (MST) Subject: [Rxtx] Win64 rxtx Testers? Message-ID: I have compiled win64 binaries of rxtx. Are there any users interested in testing them? If so, I'll look into putting them on the web site. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Mar 3 15:35:06 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 14:35:06 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: Because of this and similar problems, JMRI does all it's serial IO using +only+ byte values. It's a but of a pain, as Java wants to go to char and int types a little too aggressively, but it does solve the "uncontrolled conversions" problems. Bob At 5:10 PM -0500 3/3/07, Keith wrote: >Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > >Bob -- I think you hit the nail on the head. > >I was just coming to the same realization here. I knew that something funny >was going on because the same bytes always got "corrupted." > >I'm pretty sure its in the InputStreamReader() functionality where the >conversion junk is happening. > >Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > >I don't know if simply changing the cast is going to work. Since the >conversion is happening upstream (pun intended), I don't think my cast is >doing this. Also I think the compiler forced me to use the cast. -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mark at mdsh.com Sun Mar 4 11:01:33 2007 From: mark at mdsh.com (Mark Himsley) Date: Sun, 04 Mar 2007 18:01:33 +0000 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: <5C01AC72C200388815C04982@bedroom.mdsh.local> On 03 March 2007 14:38 -0500 Keith wrote: > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT > consistent. Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? It looks like you need to use DataInputStream and DataOutputStream. -- Mark Himsley From tjarvi at qbang.org Sun Mar 4 11:35:08 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 11:35:08 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" > > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > > * Line #21 - Not sure if you need a (TM) mark for > the term "Sun" > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > OK. I'm going through this today. Some groups ask if rxtx could be under their license also. I think this is a good example of why I resist multiple licenses and focus on why the current license may not be usable by them. The RXTX project is a convergence of hobby and commercial interests. I happen to do both right now. The problem with licensing is we have to stay on top of them as they change. Clearly, adding more licenses will not make this easier. I'm acting as the hobby person today. RXTX always favors the hobby people. But as we move forward, I'm going to need to bring this to lawyers at work and explain to them what is going on. Others here may have to do this also. I don't anticipate problems or unexpected changes. The goal is a consistant, comprehendable and usable license as close to what we have now as possible. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 14:52:10 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 14:52:10 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (1/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: I'm breaking this into two parts. I expect the second part will need more attention. Comments first, then the changed material below. On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > Thanks > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. OK. RXTX for consitent use. java should not be capitalized because it does not only mean Sun [TM] Java [TM]. An example of this not meaning Java is when people use RXTX with GCJ. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". There are not any contributors that are in all of RXTX yet but I did update the comment to try to reflect the current situation without making it a nightmare to maintain. I looked to see how the Linux kernel does it as a reference point. > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" The URL can be problematic. I have done so below with a time reference. GNU does not provide version information in their URLS. I picture this being a problem when the version 3 comes out. > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > This will be corrected when the copy is updated to the version linked below. ---------------- begin proposed material involved -------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. ----------------- end proposed material involved -------------------- I'll be looking at the linking issue again next. That should be all that remains other than including the 2.1 version. Let me know if you have problems with anything here. I do not want to dilute the material I post next with these housekeeping tasks. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 16:08:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 16:08:36 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: For those that are wondering what is going on here, this next bit is the meat of the changes. We agreed a long time ago to put this disclaimer in. We did a so so job. It was in rxtx 2.0, not well written, ... So some groups using rxtx that would like to ship rxtx so users don't need to download, install, go to the mail-list to find why it failed, ... Then their legal teams tell them section 5 paragraph 2 is a show stopper. That was never the intent. Now going through what remains... > and might need a (TM) suffix to make Sun happy. Added disclaimer at the ended 'all trademarks belong...' > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. OK. As you can see I was trying to adjust GNU text there for the LGPL. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. used dynamically linked terminology. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". I tried to address this more upfront with an intent statement. Let me know if you have problems with it. I also tried to make it a little more clear what was derived from the GNU solution by moving the link location closer to GNU's suggestion. > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > Thats the intent. Here is the combined fixes. Note that only the material in /*-- --*/ is being touched. The new GPL license is there but unmodified. ------------------------ begin proposed new license ------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. | | An executable that contains no derivative of any portion of RXTX, but | is designed to work with RXTX by being dynamically linked with it, | is considered a "work that uses the Library" subject to the terms and | conditions of the GNU Lesser General Public License. | | The following has been added to the RXTX License to remove | any confusion about linking to RXTX. We want to allow in part what | section 5, paragraph 2 of the LGPL does not permit in the special | case of linking over a controlled interface. The intent is to add a | Java Specification Request or standards body defined interface in the | future as another exception but one is not currently available. | | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface | | As a special exception, the copyright holders of RXTX give you | permission to link RXTX with independent modules that communicate with | RXTX solely through the Sun Microsytems CommAPI interface version 2, | regardless of the license terms of these independent modules, and to copy | and distribute the resulting combined work under terms of your choice, | provided that every copy of the combined work is accompanied by a complete | copy of the source code of RXTX (the version of RXTX used to produce the | combined work), being distributed under the terms of the GNU Lesser General | Public License plus this exception. An independent module is a | module which is not derived from or based on RXTX. | | Note that people who make modified versions of RXTX are not obligated | to grant this special exception for their modified versions; it is | their choice whether to do so. The GNU Lesser General Public License | gives permission to release a modified version without this exception; this | exception also makes it possible to release a modified version which | carries forward this exception. | | You should have received a copy of the GNU Lesser General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA | All trademarks belong to their respective owners. --------------------------------------------------------------------------*/ The original GNU Lesser General Public License Follows. GNU LESSER GENERAL PUBLIC LICENSE Version 2.1, February 1999 Copyright (C) 1991, 1999 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. [This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence the version number 2.1.] Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This license, the Lesser General Public License, applies to some specially designated software packages--typically libraries--of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below. When we speak of free software, we are referring to freedom of use, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish); that you receive source code or can get it if you want it; that you can change the software and use pieces of it in new free programs; and that you are informed that you can do these things. To protect your rights, we need to make restrictions that forbid distributors to deny you these rights or to ask you to surrender these rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library or if you modify it. For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights. We protect your rights with a two-step method: (1) we copyright the library, and (2) we offer you this license, which gives you legal permission to copy, distribute and/or modify the library. To protect each distributor, we want to make it very clear that there is no warranty for the free library. Also, if the library is modified by someone else and passed on, the recipients should know that what they have is not the original version, so that the original author's reputation will not be affected by problems that might be introduced by others. Finally, software patents pose a constant threat to the existence of any free program. We wish to make sure that a company cannot effectively restrict the users of a free program by obtaining a restrictive license from a patent holder. Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license. Most GNU software, including some libraries, is covered by the ordinary GNU General Public License. This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs. When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library. We call this license the "Lesser" General Public License because it does Less to protect the user's freedom than the ordinary General Public License. It also provides other free software developers Less of an advantage over competing non-free programs. These disadvantages are the reason we use the ordinary General Public License for many libraries. However, the Lesser license provides advantages in certain special circumstances. For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License. In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software. For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU operating system, as well as its variant, the GNU/Linux operating system. Although the Lesser General Public License is Less protective of the users' freedom, it does ensure that the user of a program that is linked with the Library has the freedom and the wherewithal to run that program using a modified version of the Library. The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, whereas the latter must be combined with the library in order to run. GNU LESSER GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License Agreement applies to any software library or other program which contains a notice placed by the copyright holder or other authorized party saying it may be distributed under the terms of this Lesser General Public License (also called "this License"). Each licensee is addressed as "you". A "library" means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables. The "Library", below, refers to any such software library or work which has been distributed under these terms. A "work based on the Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term "modification".) "Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library. Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does. 1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) The modified work must itself be a software library. b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change. c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License. d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful. (For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library. In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. 4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange. If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code. 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables. When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law. If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.) Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself. 6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications. You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things: a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.) b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. c) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution. d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place. e) Verify that the user has already received a copy of these materials or that you have already sent this user a copy. For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute. 7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things: a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above. b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work. 8. You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 9. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Library (or any work based on the Library), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Library or works based on it. 10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties with this License. 11. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply, and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 12. If the distribution and/or use of the Library is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Library under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 13. The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation. 14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Libraries If you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the ordinary General Public License). To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Also add information on how to contact you by electronic and paper mail. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the library, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the library `Frob' (a library for tweaking knobs) written by James Random Hacker. , 1 April 1990 Ty Coon, President of Vice That's all there is to it! ------------------------ end of proposed license ------------------ -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sun Mar 4 16:26:04 2007 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 04 Mar 2007 17:26:04 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <45EB558C.3010609@cox.net> Bob Jacobsen wrote: > Because of this and similar problems, JMRI does all it's serial IO > using +only+ byte values. It's a but of a pain, as Java wants to go > to char and int types a little too aggressively, but it does solve > the "uncontrolled conversions" problems. Anytime that you are reading bytes of data that is not printable, unicode text, in Java, you really need to stay away from the Readers. Use input stream only, or you will see unicode valued byte groups converted to unicode "char" values. Gregg Wonderly From joachim at buechse.de Mon Mar 5 04:23:48 2007 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 5 Mar 2007 12:23:48 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> The behaviour is exactly what you asked for in you code. is = new BufferedReader(new InputStreamReader(port.getInputStream())); Readers return Text (ie unicode chars) not bytes. You instantiate the InputStreamReader without saying which charset you want, which means "platform default". As this is on Windows, it will convert Windows characters to equivalent unicode characters. If you want to read bytes, read bytes not Text. Reading bytes is done with InputStream and BufferedInputStream. BTW: The InputStream and Reader methods that read arrays are not guarenteed to fill up the array. You always have to check what you really got, and advance your index accordingly. A typical "read up to 32k" method looks like this: InputStream is= ... // -- determine the max buffer size int len= is.available(); if (len == 0) { len= 32 * 1024; } // -- read all available data byte[] buffer= new byte[len]; int pos= 0; int read; do { read= is.read(buffer, pos, buffer.length - pos); pos= pos + read; } while (read != -1 && pos < buffer.length); Best regards, Joachim --- Joachim B?chse Phone: +41 44 500 2604 Buechse Consulting Hadlaubsteig 2 CH-8006 Z?rich On 03.03.2007, at 23:10, Keith wrote: > Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > > Bob -- I think you hit the nail on the head. > > I was just coming to the same realization here. I knew that > something funny > was going on because the same bytes always got "corrupted." > > I'm pretty sure its in the InputStreamReader() functionality where the > conversion junk is happening. > > Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > > I don't know if simply changing the cast is going to work. Since the > conversion is happening upstream (pun intended), I don't think my > cast is > doing this. Also I think the compiler forced me to use the cast. > > I'm still playing around, and I'll report back once I nail it down. > > Thanks!! > > Keith > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Mon Mar 5 07:25:46 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 05 Mar 2007 08:25:46 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> Message-ID: <45EC286A.8060608@cox.net> Joachim Buechse wrote: > BTW: The InputStream and Reader methods that read arrays are not > guarenteed to fill up the array. You always have to check what you > really got, and advance your index accordingly. A typical "read up to > 32k" method looks like this: > > InputStream is= ... > // -- determine the max buffer size > int len= is.available(); > if (len == 0) { > len= 32 * 1024; > } > // -- read all available data > byte[] buffer= new byte[len]; > int pos= 0; > int read; > do { > read= is.read(buffer, pos, buffer.length - pos); > pos= pos + read; > } while (read != -1 && pos < buffer.length); > My preferred structure is. byte arr[ len ]; int cnt; int off = 0; while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { off += cnt; } This keeps you from adding -1 to pos when the read returns -1. It also skips out when the read is 0 bytes which, is not a described EOF in InputStream java docs, but is a condition I want to be aware of. Gregg Wonderly From joachim at buechse.de Tue Mar 6 02:52:58 2007 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 6 Mar 2007 10:52:58 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <45EC286A.8060608@cox.net> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: The code I copied was from a file resource reader, it shouldn't really be applied to networking/external IO code. Mea culpa. However aborting when you get 0 from read is not always what you want either (you kind of indicated that already). Some unix java implementations will return 0 if the kernel read was aborted with EINTER, which is rarely the point where you want to abort your read - at least not without further checks. A "complete" solution always depends on the events you need to handle and the time the total read could take in reality. In some cases it's worth checking Thread.isInterrupted() in the loop, some code re-loops on 0 but only a limited number of times, some check a total timeout limit, etc... Best regards, Joachim On 05.03.2007, at 15:25, Gregg Wonderly wrote: > My preferred structure is. > > byte arr[ len ]; > int cnt; > int off = 0; > while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { > off += cnt; > } > > This keeps you from adding -1 to pos when the read returns -1. It > also skips > out when the read is 0 bytes which, is not a described EOF in > InputStream java > docs, but is a condition I want to be aware of. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Mar 6 14:47:44 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 Mar 2007 14:47:44 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: Just FYI, rxtx will usually not break out on EINTER. The code in the native library usually does something close to this: do { read(...) } while ( !done && errno==EINTR ); Obviously there is a little more involved but it will retry on EINTER if not done. On Tue, 6 Mar 2007, Joachim Buechse wrote: > The code I copied was from a file resource reader, it shouldn't > really be applied to networking/external IO code. Mea culpa. > > However aborting when you get 0 from read is not always what you want > either (you kind of indicated that already). Some unix java > implementations will return 0 if the kernel read was aborted with > EINTER, which is rarely the point where you want to abort your read - > at least not without further checks. A "complete" solution always > depends on the events you need to handle and the time the total read > could take in reality. In some cases it's worth checking > Thread.isInterrupted() in the loop, some code re-loops on 0 but only > a limited number of times, some check a total timeout limit, etc... > > Best regards, > Joachim > > On 05.03.2007, at 15:25, Gregg Wonderly wrote: >> My preferred structure is. >> >> byte arr[ len ]; >> int cnt; >> int off = 0; >> while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { >> off += cnt; >> } >> >> This keeps you from adding -1 to pos when the read returns -1. It >> also skips >> out when the read is 0 bytes which, is not a described EOF in >> InputStream java >> docs, but is a condition I want to be aware of. >> >> Gregg Wonderly >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 gjhanna at gmail.com Thu Mar 8 13:42:52 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Fri, 9 Mar 2007 09:42:52 +1300 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? Message-ID: I've just struck an issue using rxtx in a multi-threaded environment: If I have 3 threads trying to open *the same* comm-port I get a deadlock in CommPortIdentifier.open If I have just 2, it works fine - I get a PortInUseException which is nice and I can handle it. The 3 thread->deadlock thing is causing me issues. (Sample code below). This is from the java thread-dump Found one Java-level deadlock: ============================= "Thread-2": waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object ), which is held by "Thread-1" "Thread-1": waiting to lock monitor 0x0003e9cc (object 0x2450e108, a gnu.io.CommPortIdentifier), which is held by "Thread-2" Java stack information for the threads listed above: =================================================== "Thread-2": at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:329) - waiting to lock <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) "Thread-1": at java.lang.Object.wait(Native Method) - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) - locked <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) (Apart from this, rxtx is working fantastically for us). I'm thinking I'll have to implement some sort of locking mechanism that *doesn't* use java synchronization to prevent this situation. (Which doesn't sound like a good idea to me). Any ideas? Thanks, Greg Hanna ============= RXTXLockTest.java ======================================== import gnu.io.CommPort; import gnu.io.CommPortIdentifier; /** * @author Greg Hanna * Minimal code to create a deadlock with rxtx in multithreaded open */ public class RXTXLockTest { public static void main(String[] args) { try { CommPortIdentifier cpiCom1 = CommPortIdentifier.getPortIdentifier ("COM14"); OpenThread t1 = new OpenThread (" one ", cpiCom1); OpenThread t2 = new OpenThread (" two ", cpiCom1); OpenThread t3 = new OpenThread (" 003 ", cpiCom1); t1.start(); t2.start(); t3.start(); // comment this out and it runs with (expected) PortInUseException } catch (Exception e) { e.printStackTrace(); } } } class OpenThread extends Thread { String name; CommPortIdentifier cpi; CommPort cp; public OpenThread (String name, CommPortIdentifier cpi) { this.name = name; this.cpi = cpi; System.out.println (System.currentTimeMillis() + name + " thread created"); } public void run () { try { System.out.println (System.currentTimeMillis() + name + " opening"); cp = cpi.open(name, 2000); System.out.println (System.currentTimeMillis() + name + " opened - sleeping"); sleep (2000); // do the serial comms with the device. System.out.println (System.currentTimeMillis() + name + " slept - closing"); cp.close(); System.out.println (System.currentTimeMillis() + name + " closed - exiting"); } catch (Exception e) { System.out.println ("Error in thread: " + name ); e.printStackTrace(); } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070308/d9a163c5/attachment-0090.html From eu259473 at tele2.it Fri Mar 9 02:46:20 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 09 Mar 2007 10:46:20 +0100 Subject: [Rxtx] rxtx: tru64 unix make fails Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070309/3b654523/attachment-0090.html From lyon at docjava.com Fri Mar 9 03:58:32 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 Mar 2007 05:58:32 -0500 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi All, The deadlock issue is one that I have been thinking about for some time now. It seems to me that we need a resource manager that enables assignment to a known process. The one thing that seems important about serial ports is that two applications should not use the same serial port at the same time. When this happens, it throws an exception. OK. The exception is a response to a lock condition that arises from an unavailable resource. An abstract implementation (not born of native methods) might assign a serial port to an application, until the application releases it (or is forced to release it by some kill mechanism). Some resources (like a registry) can be reused. But others, like the serial port, cannot. In the case of the serial port, we would like, I think, to have the flyweight design pattern without sharing and with object assignment tracking. A means of breaking deadlock (like a leasing mechanism) seems very useful, to me. My guess is that we can serialize the state of the Parametric Singleton Pattern (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) into the Preferences of the System. Preferences.systemRoot() might help with that. When a resource is checked out, the lease time and owner are listed. A thread that does this can be killed, but applications outside of Java are problematic. There is a compelling problem here. It is not just serial ports. Sound cards, cameras, microphones, files, tape drives, etc. All are consumed resources that are assigned to an application (or user) and deprive other applications, or users, from use. What, if anything, should we do? At present we throw PortInUseExceptions. Is that it? Can we do better? OK, the port is in use. Now what? Do I have to be root to go remove lock files and kill applications? Is there a better way? Thanks! - Doug >I've just struck an issue using rxtx in a multi-threaded environment: > >If I have 3 threads trying to open *the same* >comm-port I get a deadlock in >CommPortIdentifier.open >If I have just 2, it works fine - I get a >PortInUseException which is nice and I can >handle it. > >The 3 thread->deadlock thing is causing me issues. >(Sample code below). > >This is from the java thread-dump > >Found one Java-level deadlock: >============================= >"Thread-2": > waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), > which is held by "Thread-1" >"Thread-1": > waiting to lock monitor 0x0003e9cc (object >0x2450e108, a gnu.io.CommPortIdentifier ), > which is held by "Thread-2" > >Java stack information for the threads listed above: >=================================================== >"Thread-2": > at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) > - waiting to lock <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) >"Thread-1": > at java.lang.Object.wait(Native Method) > - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) > - locked <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) > > >(Apart from this, rxtx is working fantastically for us). > >I'm thinking I'll have to implement some sort of >locking mechanism that *doesn't* use java >synchronization to prevent this situation. >(Which doesn't sound like a good idea to me). > >Any ideas? > >Thanks, > >Greg Hanna > >============= RXTXLockTest.java ======================================== > >import gnu.io.CommPort; >import gnu.io.CommPortIdentifier; > >/** > * @author Greg Hanna > * Minimal code to create a deadlock with rxtx in multithreaded open > */ >public class RXTXLockTest { > ? > ?public static void main(String[] args) { > ?try { > ?CommPortIdentifier cpiCom1 = >CommPortIdentifier.getPortIdentifier ("COM14"); > ?OpenThread t1 = new OpenThread (" one ", cpiCom1); > ?OpenThread t2 = new OpenThread (" two ", cpiCom1); > ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); > ?t1.start(); > ?t2.start(); > ?t3.start(); // comment this out >and it runs with (expected) PortInUseException > ?} catch (Exception e) { > ?e.printStackTrace(); > ?} > ?} >} > >class OpenThread extends Thread { > ?String name; > ?CommPortIdentifier cpi; > ?CommPort cp; > ?public OpenThread (String name, CommPortIdentifier cpi) { > ? this.name = name; > ?this.cpi = cpi; > ?System.out.println >(System.currentTimeMillis() + name + " thread >created"); > ?} > ?public void run () { > ?try { > ?System.out.println >(System.currentTimeMillis() + name + " opening"); > ?cp = cpi.open(name, 2000); > ?System.out.println >(System.currentTimeMillis() + name + " opened - >sleeping"); > ?sleep (2000); // do the serial comms with the device. > ?System.out.println >(System.currentTimeMillis() + name + " slept - >closing"); > ?cp.close(); > ?System.out.println >(System.currentTimeMillis() + name + " closed - >exiting"); > ?} catch (Exception e) { > System.out.println ("Error in thread: " + name ); > ?e.printStackTrace(); > ?} > ?} >} > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Mar 9 06:37:45 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 Mar 2007 06:37:45 -0700 (MST) Subject: [Rxtx] rxtx: tru64 unix make fails In-Reply-To: References: Message-ID: On Fri, 9 Mar 2007, "Giuseppe Marchese" wrote: > Sorry for delay. > ? > This is log for ./configure and make > error. > ? > thanks for attention > ? > Make: '%.java,$(TOP)/$(CLASSDEST)/%.class,$(wildcard $(SPATH)/*.java)': extra chars.? > Stop. > Hi Giuseppe You need to use GNU make with the Makefile. I suspect the tru64 make is not happy with those rules. > configure: exit 0 Looks like configure is fairly happy. From tjarvi at qbang.org Sat Mar 10 07:43:51 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 07:43:51 -0700 (MST) Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi Doug I have very little time to look into this further but what we could do is open up an rxtx 3 devel branch in which a proof of concept could be worked on. It could be the proof of concept for a JSR others including Sun could look at/work on or parts of it could be recycled in a JSR. I'm working very hard on rxtx right now but it does not show. I'm looking at win64, mac intel/ppc, usb bluetooth and usb serial dongles. Some are going to be more tested than others but they are all on the plate. I'll be pushing all the fixes upstream when they are done. So I'm very busy in 2.1 but we could open a new branch. On Fri, 9 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > The deadlock issue is one that I have been thinking about > for some time now. > It seems to me that we need a resource manager that enables assignment > to a known process. > > The one thing that seems important about serial > ports is that two applications should not use the > same serial port at the same time. When this > happens, it throws an exception. > OK. > > The exception is a response to a lock condition that > arises from an unavailable resource. > > An abstract implementation (not born of native methods) might > assign a serial port to an application, until the > application releases it (or is forced to release > it by some kill mechanism). > > Some resources (like a registry) can be reused. > But others, like the serial port, > cannot. > > In the case of the serial port, we would like, I think, to > have the flyweight design pattern > without sharing and with object assignment tracking. > A means of breaking deadlock (like a leasing > mechanism) seems very useful, to me. > > My guess is that we can serialize the state of the Parametric Singleton Pattern > (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) > into the Preferences of the System. Preferences.systemRoot() might help > with that. When a resource is checked out, the lease time and owner are > listed. A thread that does this can be killed, but applications outside of Java > are problematic. > > There is a compelling problem here. It is not just serial ports. > Sound cards, cameras, microphones, files, tape drives, etc. All are consumed > resources that are assigned to an application (or > user) and deprive other applications, > or users, from use. > > What, if anything, should we do? At present we throw PortInUseExceptions. > Is that it? > Can we do better? > OK, the port is in use. Now what? > Do I have to be root to go remove lock files and kill applications? > Is there a better way? > > Thanks! > - Doug > >> I've just struck an issue using rxtx in a multi-threaded environment: >> >> If I have 3 threads trying to open *the same* >> comm-port I get a deadlock in >> CommPortIdentifier.open >> If I have just 2, it works fine - I get a >> PortInUseException which is nice and I can >> handle it. >> >> The 3 thread->deadlock thing is causing me issues. >> (Sample code below). >> >> This is from the java thread-dump >> >> Found one Java-level deadlock: >> ============================= >> "Thread-2": >> waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), >> which is held by "Thread-1" >> "Thread-1": >> waiting to lock monitor 0x0003e9cc (object >> 0x2450e108, a gnu.io.CommPortIdentifier ), >> which is held by "Thread-2" >> >> Java stack information for the threads listed above: >> =================================================== >> "Thread-2": >> at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) >> - waiting to lock <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> "Thread-1": >> at java.lang.Object.wait(Native Method) >> - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) >> - locked <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> >> >> (Apart from this, rxtx is working fantastically for us). >> >> I'm thinking I'll have to implement some sort of >> locking mechanism that *doesn't* use java >> synchronization to prevent this situation. >> (Which doesn't sound like a good idea to me). >> >> Any ideas? >> >> Thanks, >> >> Greg Hanna >> >> ============= RXTXLockTest.java ======================================== >> >> import gnu.io.CommPort; >> import gnu.io.CommPortIdentifier; >> >> /** >> * @author Greg Hanna >> * Minimal code to create a deadlock with rxtx in multithreaded open >> */ >> public class RXTXLockTest { >> ? >> ?public static void main(String[] args) { >> ?try { >> ?CommPortIdentifier cpiCom1 = >> CommPortIdentifier.getPortIdentifier ("COM14"); >> ?OpenThread t1 = new OpenThread (" one ", cpiCom1); >> ?OpenThread t2 = new OpenThread (" two ", cpiCom1); >> ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); >> ?t1.start(); >> ?t2.start(); >> ?t3.start(); // comment this out >> and it runs with (expected) PortInUseException >> ?} catch (Exception e) { >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> class OpenThread extends Thread { >> ?String name; >> ?CommPortIdentifier cpi; >> ?CommPort cp; >> ?public OpenThread (String name, CommPortIdentifier cpi) { >> ? this.name = name; >> ?this.cpi = cpi; >> ?System.out.println >> (System.currentTimeMillis() + name + " thread >> created"); >> ?} >> ?public void run () { >> ?try { >> ?System.out.println >> (System.currentTimeMillis() + name + " opening"); >> ?cp = cpi.open(name, 2000); >> ?System.out.println >> (System.currentTimeMillis() + name + " opened - >> sleeping"); >> ?sleep (2000); // do the serial comms with the device. >> ?System.out.println >> (System.currentTimeMillis() + name + " slept - >> closing"); >> ?cp.close(); >> ?System.out.println >> (System.currentTimeMillis() + name + " closed - >> exiting"); >> ?} catch (Exception e) { >> System.out.println ("Error in thread: " + name ); >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 mm at UDel.Edu Sat Mar 10 14:48:32 2007 From: mm at UDel.Edu (Mike Markowski) Date: Sat, 10 Mar 2007 16:48:32 -0500 Subject: [Rxtx] rxtx and Sun's comm api Message-ID: <45F327B0.2060004@udel.edu> Hi all, I joined the list a few days ago and apologize for what is likely a frequently asked question, though I haven't yet found it anywhere. I learned about rxtx.org through the readme on Sun's version 2 of their comms api. They give recommendations in that readme regarding how a better comms api should be written. Is this the aim of rxtx.org? I wrote an app on my linux box using the Sun comms api (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the fact that only linux and Solaris are supported. So I'm glad to find rxtx.org and am just reading up on how make the conversion so Windows users will be able to run the program as well. At the same time I'm just curious if rxtx.org and Sun are both heading in the same direction. Thanks for any background or historical info. Feel free to point me to any www pages if my googling has just completely missed the target! Thanks again, Mike From tjarvi at qbang.org Sat Mar 10 15:35:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 15:35:25 -0700 (MST) Subject: [Rxtx] rxtx and Sun's comm api In-Reply-To: <45F327B0.2060004@udel.edu> References: <45F327B0.2060004@udel.edu> Message-ID: On Sat, 10 Mar 2007, Mike Markowski wrote: > Hi all, > > I joined the list a few days ago and apologize for what is likely a > frequently asked question, though I haven't yet found it anywhere. I > learned about rxtx.org through the readme on Sun's version 2 of their > comms api. They give recommendations in that readme regarding how a > better comms api should be written. Is this the aim of rxtx.org? > > I wrote an app on my linux box using the Sun comms api > (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the > fact that only linux and Solaris are supported. So I'm glad to find > rxtx.org and am just reading up on how make the conversion so Windows > users will be able to run the program as well. At the same time I'm > just curious if rxtx.org and Sun are both heading in the same direction. > > Thanks for any background or historical info. Feel free to point me to > any www pages if my googling has just completely missed the target! > I do not have any news (good or bad) concerning RXTX and Sun working together but perhaps others here do. The main goal of RXTX is to expose POSIX termios interfaces to java users. The future support of javax.comm is questionable. We do not have resources for everything. gnu.io (RXTX 2.1) will be supported going forward and functions the same as CommAPI 2.0. If you have control of the source code you are working with, I would not advise using CommAPI 2.0 javax.comm. We do support CommAPI 2.0 javax.comm for older applications but I do not think that will last much longer for practical reasons. The download interest in CommAPI 2.0 javax.comm support is becomming negligible on this end. There has been discussion of a JSR effort but I do not know of any status change since it was mentioned. One problem with a JSR is that even a light weight process is going to be difficult for RXTX at this time. Maybe that will change in the future but then again it may not. For now, we are just going forward 'as is' in rxtx 2.1 with package gnu.io while trying as a secondary effort to backport the changes to rxtx 2.0 for javax.comm support for users that do not have a choice. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Mar 11 07:19:40 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 11 Mar 2007 08:19:40 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: Hi All, I have been a proponent of a JSR that makes use of RXTX. I have executed the proper agreements with Sun. At this point we are in the: Early Draft Review of Draft Specifications Stage. The best thing to do is to enter the quiet period and create a specification. The question of exactly how we, as a group, want to approach this problem, remains open. Typically, we should have both a specification and a reference implementation. Thus, it would be to our best advantage to have a nice, stable, cross platform RXTX distro that adheres to the groups specification. Now, from a specification standpoint, my personal view on the matter is that we create a series of interfaces, with nice documentation (or at least javadoc). Is this a good idea? Should we have a pure interface specification for the communication API? There are several issues, in my mind, which still weigh on us. Hot-pluggable dongles, long discovery process on pop-up ports, lack of uniformity on device names, lack of uniformity on locking, a precise understanding of how the SerialPortResourceManager works (or even if we should have one). The more questions we answer in our reference implementation, the better our specification will get. RXTX is a good working prototype, but, I don't know if that is what we want to use for a specification. Here is what I have for a CommPortInterface: */ public interface CommPortInterface { /** * @return a string representation of this port. */ String toString(); /** * Gets the name of the communications port. This name should correspond to * something the user can identify, like the label on the hardware. * @return name of the port */ String getName(); /** * @return an input stream that can be used to read data from the * communications port. If the port doesn't support reading data, this * method returns null. *

* The blocking behaviour of this input stream depends on the threshold * and timeout values, as shown below for a read buffer size of n * bytes: * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ThresholdTimeoutBlocking behaviour
StateValueStateValue
disableddisabledblock until data is available
enabledm bytesdisabledblock until min(m, n) bytes are available
disabledenabledt msblock for t ms or until data is available
enabledm bytesenabledt msblock for t ms or until min(m, n) bytes are * available
* @throws java.io.IOException */ InputStream getInputStream() throws IOException; /** * @return an output stream that can be used to send data to the * communications port. If the port doesn't support sending data, this * method returns null. * @throws java.io.IOException */ OutputStream getOutputStream() throws IOException; /** * Closes this communications port. * All PortOwnershipListeners will be? * notified of this change of ownership. Further method calls on this? * object will throw IllegalStateException. Further calls on the? * associated InputStream or OutputStream will throw IOException. *

* Close does not block. Undelivered data is discarded. Blocked read and? * write operations are aborted if the underlying operating systems? * supports an IO abort mechanism. To await the delivery of undelivered? * data call OutputStream.flush() or OutputStream.close() before calling? * Port.close(). */ void close(); /** * Enables receive threshold. * When the specified threshold number of bytes are retrieved, read will * return immediately. * * @param thresh the number of bytes in the input buffer * @throws gnu.io.UnsupportedCommOperationException * if receive threshold is * not supported by the driver * @see #disableReceiveThreshold */ void enableReceiveThreshold(int thresh) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive threshold. * * @see #enableReceiveThreshold */ void disableReceiveThreshold(); /** * @return true if receive threshold is enabled. * * @see #enableReceiveThreshold */ boolean isReceiveThresholdEnabled(); /** * @return the receive threshold value. If receive threshold is diabled * or not supported, this value is meaningless. * * @see #enableReceiveThreshold */ int getReceiveThreshold(); /** * Enables receive timeout. * When the specified number of milliseconds have elapsed, read will * return immediately. * * @param rcvTimeout the number of milliseconds to block for * @throws gnu.io.UnsupportedCommOperationException * if receive timeout is * not supported by the driver * @see #disableReceiveTimeout */ void enableReceiveTimeout(int rcvTimeout) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive timeout. * * @see #enableReceiveTimeout */ void disableReceiveTimeout(); /** * @return true if receive timeout is enabled. * * @see #enableReceiveTimeout */ boolean isReceiveTimeoutEnabled(); /** * @return the receive timeout value. If receive timeout is diabled * or not supported, this value is meaningless. * * @see #enableReceiveTimeout */ int getReceiveTimeout(); /** * Enables receive framing. * The supplied byte value in the input suggests the end of the received * frame, and read returns immediately. Only the low 8 bits of the * supplied value are significant. * * @param framingByte the frame delimiter * @throws gnu.io.UnsupportedCommOperationException * if receive framing is * not supported by the driver * @see #disableReceiveFraming */ void enableReceiveFraming(int framingByte) throws UnsupportedCommOperationException; /** * Disables receive framing. * * @see #enableReceiveFraming */ void disableReceiveFraming(); /** * @return true if receive framing is enabled. * * @see #enableReceiveFraming */ boolean isReceiveFramingEnabled(); /** * @return true if receive framing byte. If receive framing is diabled * or not supported, this value is meaningless. * * @see #enableReceiveFraming */ int getReceiveFramingByte(); /** * Sets the input buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setInputBufferSize(int size); /** * @return the input buffer size. * The driver may choose not to report correct values. */ int getInputBufferSize(); /** * Sets the output buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setOutputBufferSize(int size); /** * @return the output buffer size. * The driver may choose not to report correct values. */ int getOutputBufferSize(); } What do you think of that? Note the wishy washy nature of the spec: The driver may choose to ignore this method. Is that good enough for us? Thanks! - Doug From ra85551 at gmail.com Sun Mar 11 08:44:45 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Sun, 11 Mar 2007 17:44:45 +0300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hello, world! I am writing application that communicates with modem via AT commands. My OS is Linux Kubuntu Feisty Herd, to ensure that my application will run properly under Windows XP I installed VMWare server. When I tried to send AT command and evaluate modem answer under WinXP @ VMWare server, I actually didn't receive anything. I think that VM settings are right, because I do can communicate with modem by using standard HyperTerminall as well as I can do on native Windows. So, why RXTX doesn't work under VM, but works under Linux and pure Windows XP (i tested it there) well? The send/receive method code follows. private String sendATCommand(String command, final String waitFor, final boolean isRegex, boolean isAddCRLF, long timeout) throws BeaconConnectException { final long POLL_PERIOD = 100; final int BUFFER_SIZE = 512; final byte[] buffer = new byte[BUFFER_SIZE]; final InputStream serialInput; final OutputStream serialOutput; try { serialInput = serialPort.getInputStream(); if (command != null) { serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } } catch (IOException e) { throw new MyException("serial I/O error"); } TimerTask task = new TimerTask() { int offset = 0; int bytesRead; public synchronized void run() { try { if (serialInput.available() > 0) { bytesRead = serialInput.read(buffer, offset, BUFFER_SIZE - offset); } else { return; } } catch (IOException e) { // do nothing - maybe next time we'll read something } offset += bytesRead; if (waitFor != null) { String temporary = new String(buffer, 0, offset).trim(); if (isRegex && temporary.matches(waitFor) || temporary.contains(waitFor)) { cancel(); notify(); } } } }; Timer timer = new Timer(); timer.schedule(task, POLL_PERIOD, POLL_PERIOD); synchronized (task) { try { task.wait(timeout); task.cancel(); } catch (InterruptedException e) { } } //Cut off leading and trailing CRs, LFs and zeroes String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); System.out.println(response); return response; } -- Pavel Parkhomenko From tjarvi at qbang.org Sun Mar 11 11:48:22 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:48:22 -0600 (MDT) Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: On Sun, 11 Mar 2007, Pavel Parkhomenko wrote: > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. > > private String sendATCommand(String command, final String waitFor, > final boolean isRegex, boolean isAddCRLF, long timeout) > throws BeaconConnectException > { > final long POLL_PERIOD = 100; > final int BUFFER_SIZE = 512; > final byte[] buffer = new byte[BUFFER_SIZE]; > final InputStream serialInput; > final OutputStream serialOutput; > try > { > serialInput = serialPort.getInputStream(); > if (command != null) > { > serialOutput = serialPort.getOutputStream(); > if (isAddCRLF) > { > command += "\r\n"; > } > System.out.println(command); > serialOutput.write(command.getBytes()); > } > } > catch (IOException e) > { > throw new MyException("serial I/O error"); > } > > TimerTask task = new TimerTask() > { > int offset = 0; > int bytesRead; > public synchronized void run() > { > try > { > if (serialInput.available() > 0) > { > bytesRead = serialInput.read(buffer, offset, > BUFFER_SIZE - offset); > } > else > { > return; > } > } > catch (IOException e) > { > // do nothing - maybe next time we'll read something > } > offset += bytesRead; > if (waitFor != null) > { > String temporary = new String(buffer, 0, offset).trim(); > if (isRegex && temporary.matches(waitFor) || > temporary.contains(waitFor)) > { > cancel(); > notify(); > } > } > } > }; > > Timer timer = new Timer(); > timer.schedule(task, POLL_PERIOD, POLL_PERIOD); > synchronized (task) { > try > { > task.wait(timeout); > task.cancel(); > } > catch (InterruptedException e) > { > } > } > //Cut off leading and trailing CRs, LFs and zeroes > String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); > System.out.println(response); > return response; > } > > > Hi Pavel VMWare should not be a problem. I've used it in the past - though not with a modem. Make sure nothing else is using the modem. Then look in the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an example that should work. Note that modems could care less what OS is on top. If you are trying to match new lines to the OS and sending it to the mode for AT commands, thats probably a mistake. Also it would not hurt to print out the individual bytes that you are sending to make sure they did not get mangled along the path. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 11:55:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:55:48 -0600 (MDT) Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: On Sun, 11 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > I have been a proponent of a JSR that makes > use of RXTX. I have executed the proper agreements with Sun. > > At this point we are in the: > Early Draft Review of Draft Specifications Stage. > > The best thing to do is to enter the quiet period and create > a specification. The question of exactly how we, as a group, > want to approach this problem, remains open. > > Typically, we should have both a specification and a reference > implementation. Thus, it would be to our best advantage to have > a nice, stable, cross platform RXTX distro that adheres to the > groups specification. > > Now, from a specification standpoint, my personal view on the matter is > that we create a series of interfaces, with nice documentation (or at least > javadoc). > > Is this a good idea? Should we have a pure interface specification for > the communication API? > > There are several issues, in my mind, which still weigh on us. > Hot-pluggable dongles, long discovery process on pop-up ports, > lack of uniformity on device names, lack of uniformity on locking, > a precise understanding of how the SerialPortResourceManager > works (or even if we should have one). > > The more questions we answer in our reference implementation, the > better our specification will get. RXTX is a good working prototype, > but, I don't know if that is what we want to use for a specification. > > Here is what I have for a CommPortInterface: > */ > public interface CommPortInterface { Hi Doug, I can start going through the method interfaces later this week and giving feedback. I would suggest that the JSR should not be too generic in nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel drivers that intend to look like EIA232 ports at the kernel driver level. some ideas: EIA232PortInterface TermiosInterface SerialPortInterface Something that differentiates this from thing like USB, I2C, ... which should not have to deal with legacy serial claiming to be the comm api. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 12:52:19 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 12:52:19 -0600 (MDT) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: No news is good news with these posts. I'll start the process of pinging legal a week from Monday on my end if nobody has objections to the proposal. I just want to make sure everyone has time to raise objections. Obviously, anyone can fork from a previous version if they don't like the new license. I suspect we can avoid that though. On Sun, 4 Mar 2007, Trent Jarvi wrote: > > For those that are wondering what is going on here, this > next bit is the meat of the changes. We agreed a long time > ago to put this disclaimer in. We did a so so job. It was > in rxtx 2.0, not well written, ... So some groups using > rxtx that would like to ship rxtx so users don't need to > download, install, go to the mail-list to find why it failed, > ... Then their legal teams tell them section 5 paragraph 2 > is a show stopper. > > That was never the intent. > > > Now going through what remains... > >> and might need a (TM) suffix to make Sun happy. > > Added disclaimer at the ended 'all trademarks belong...' > >> * Line #15ff - static vs. dynamic linking - you did >> not transcribe the text from the "controlled >> interface exception" when writing this text - and >> this was good so, because these terms originally >> refer to the GPL rather than the LGPL. I think though, >> that these 4 lines are the most important ones and >> should thus be really really clear. I hope that I >> meet your original intent with the following >> suggestions: >> 1.) Instead of "A program.." it would be better to >> say "An exectuable.." in order to be closer to >> the LGPL text. > > OK. As you can see I was trying to adjust GNU text there > for the LGPL. > >> 2.) It would be better to say .. "by being dynamically >> linked with it" to clearly indicate that dynamic >> linking is meant. The matter of compilation is >> already covered by the LGPL so mentioning it again >> just leads to confusion. > > used dynamically linked terminology. > >> 3.) It would be better to say .. "is considered a >> work that uses the library in contrast to section >> 5 of the LGPL, so the terms of the LGPL do not >> apply to the resulting executable". > > I tried to address this more upfront with an intent statement. > Let me know if you have problems with it. I also tried to > make it a little more clear what was derived from the GNU > solution by moving the link location closer to GNU's suggestion. > >> >> Note that LGPL section 5 says: ..."is called a >> "work that uses the Library". Such a work, in isolation, >> is not a derivative work of the Library, and therefore >> falls outside the scope of this License." >> The next paragraph of the LGPL is exactly the problematic >> one that I hope is clarified by the exception terms you >> give. >> > > Thats the intent. Here is the combined fixes. Note that only the > material in /*-- --*/ is being touched. The new GPL license is > there but unmodified. > > > ------------------------ begin proposed new license ------------------- > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Lesser General Public > | License as published by the Free Software Foundation; either > | version 2.1 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Lesser General Public License for more details. > | > | An executable that contains no derivative of any portion of RXTX, but > | is designed to work with RXTX by being dynamically linked with it, > | is considered a "work that uses the Library" subject to the terms and > | conditions of the GNU Lesser General Public License. > | > | The following has been added to the RXTX License to remove > | any confusion about linking to RXTX. We want to allow in part what > | section 5, paragraph 2 of the LGPL does not permit in the special > | case of linking over a controlled interface. The intent is to add a > | Java Specification Request or standards body defined interface in the > | future as another exception but one is not currently available. > | > | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface > | > | As a special exception, the copyright holders of RXTX give you > | permission to link RXTX with independent modules that communicate with > | RXTX solely through the Sun Microsytems CommAPI interface version 2, > | regardless of the license terms of these independent modules, and to copy > | and distribute the resulting combined work under terms of your choice, > | provided that every copy of the combined work is accompanied by a complete > | copy of the source code of RXTX (the version of RXTX used to produce the > | combined work), being distributed under the terms of the GNU Lesser General > | Public License plus this exception. An independent module is a > | module which is not derived from or based on RXTX. > | > | Note that people who make modified versions of RXTX are not obligated > | to grant this special exception for their modified versions; it is > | their choice whether to do so. The GNU Lesser General Public License > | gives permission to release a modified version without this exception; this > | exception also makes it possible to release a modified version which > | carries forward this exception. > | > | You should have received a copy of the GNU Lesser General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > | All trademarks belong to their respective owners. > --------------------------------------------------------------------------*/ > > The original GNU Lesser General Public License Follows. > > > GNU LESSER GENERAL PUBLIC LICENSE > Version 2.1, February 1999 > > Copyright (C) 1991, 1999 Free Software Foundation, Inc. > 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > Everyone is permitted to copy and distribute verbatim copies > of this license document, but changing it is not allowed. > > [This is the first released version of the Lesser GPL. It also counts > as the successor of the GNU Library Public License, version 2, hence > the version number 2.1.] > > Preamble > > The licenses for most software are designed to take away your > freedom to share and change it. By contrast, the GNU General Public > Licenses are intended to guarantee your freedom to share and change > free software--to make sure the software is free for all its users. > > This license, the Lesser General Public License, applies to some > specially designated software packages--typically libraries--of the > Free Software Foundation and other authors who decide to use it. You > can use it too, but we suggest you first think carefully about whether > this license or the ordinary General Public License is the better > strategy to use in any particular case, based on the explanations below. > > When we speak of free software, we are referring to freedom of use, > not price. Our General Public Licenses are designed to make sure that > you have the freedom to distribute copies of free software (and charge > for this service if you wish); that you receive source code or can get > it if you want it; that you can change the software and use pieces of > it in new free programs; and that you are informed that you can do > these things. > > To protect your rights, we need to make restrictions that forbid > distributors to deny you these rights or to ask you to surrender these > rights. These restrictions translate to certain responsibilities for > you if you distribute copies of the library or if you modify it. > > For example, if you distribute copies of the library, whether gratis > or for a fee, you must give the recipients all the rights that we gave > you. You must make sure that they, too, receive or can get the source > code. If you link other code with the library, you must provide > complete object files to the recipients, so that they can relink them > with the library after making changes to the library and recompiling > it. And you must show them these terms so they know their rights. > > We protect your rights with a two-step method: (1) we copyright the > library, and (2) we offer you this license, which gives you legal > permission to copy, distribute and/or modify the library. > > To protect each distributor, we want to make it very clear that > there is no warranty for the free library. Also, if the library is > modified by someone else and passed on, the recipients should know > that what they have is not the original version, so that the original > author's reputation will not be affected by problems that might be > introduced by others. > > Finally, software patents pose a constant threat to the existence of > any free program. We wish to make sure that a company cannot > effectively restrict the users of a free program by obtaining a > restrictive license from a patent holder. Therefore, we insist that > any patent license obtained for a version of the library must be > consistent with the full freedom of use specified in this license. > > Most GNU software, including some libraries, is covered by the > ordinary GNU General Public License. This license, the GNU Lesser > General Public License, applies to certain designated libraries, and > is quite different from the ordinary General Public License. We use > this license for certain libraries in order to permit linking those > libraries into non-free programs. > > When a program is linked with a library, whether statically or using > a shared library, the combination of the two is legally speaking a > combined work, a derivative of the original library. The ordinary > General Public License therefore permits such linking only if the > entire combination fits its criteria of freedom. The Lesser General > Public License permits more lax criteria for linking other code with > the library. > > We call this license the "Lesser" General Public License because it > does Less to protect the user's freedom than the ordinary General > Public License. It also provides other free software developers Less > of an advantage over competing non-free programs. These disadvantages > are the reason we use the ordinary General Public License for many > libraries. However, the Lesser license provides advantages in certain > special circumstances. > > For example, on rare occasions, there may be a special need to > encourage the widest possible use of a certain library, so that it becomes > a de-facto standard. To achieve this, non-free programs must be > allowed to use the library. A more frequent case is that a free > library does the same job as widely used non-free libraries. In this > case, there is little to gain by limiting the free library to free > software only, so we use the Lesser General Public License. > > In other cases, permission to use a particular library in non-free > programs enables a greater number of people to use a large body of > free software. For example, permission to use the GNU C Library in > non-free programs enables many more people to use the whole GNU > operating system, as well as its variant, the GNU/Linux operating > system. > > Although the Lesser General Public License is Less protective of the > users' freedom, it does ensure that the user of a program that is > linked with the Library has the freedom and the wherewithal to run > that program using a modified version of the Library. > > The precise terms and conditions for copying, distribution and > modification follow. Pay close attention to the difference between a > "work based on the library" and a "work that uses the library". The > former contains code derived from the library, whereas the latter must > be combined with the library in order to run. > > GNU LESSER GENERAL PUBLIC LICENSE > TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION > > 0. This License Agreement applies to any software library or other > program which contains a notice placed by the copyright holder or > other authorized party saying it may be distributed under the terms of > this Lesser General Public License (also called "this License"). > Each licensee is addressed as "you". > > A "library" means a collection of software functions and/or data > prepared so as to be conveniently linked with application programs > (which use some of those functions and data) to form executables. > > The "Library", below, refers to any such software library or work > which has been distributed under these terms. A "work based on the > Library" means either the Library or any derivative work under > copyright law: that is to say, a work containing the Library or a > portion of it, either verbatim or with modifications and/or translated > straightforwardly into another language. (Hereinafter, translation is > included without limitation in the term "modification".) > > "Source code" for a work means the preferred form of the work for > making modifications to it. For a library, complete source code means > all the source code for all modules it contains, plus any associated > interface definition files, plus the scripts used to control compilation > and installation of the library. > > Activities other than copying, distribution and modification are not > covered by this License; they are outside its scope. The act of > running a program using the Library is not restricted, and output from > such a program is covered only if its contents constitute a work based > on the Library (independent of the use of the Library in a tool for > writing it). Whether that is true depends on what the Library does > and what the program that uses the Library does. > > 1. You may copy and distribute verbatim copies of the Library's > complete source code as you receive it, in any medium, provided that > you conspicuously and appropriately publish on each copy an > appropriate copyright notice and disclaimer of warranty; keep intact > all the notices that refer to this License and to the absence of any > warranty; and distribute a copy of this License along with the > Library. > > You may charge a fee for the physical act of transferring a copy, > and you may at your option offer warranty protection in exchange for a > fee. > > 2. You may modify your copy or copies of the Library or any portion > of it, thus forming a work based on the Library, and copy and > distribute such modifications or work under the terms of Section 1 > above, provided that you also meet all of these conditions: > > a) The modified work must itself be a software library. > > b) You must cause the files modified to carry prominent notices > stating that you changed the files and the date of any change. > > c) You must cause the whole of the work to be licensed at no > charge to all third parties under the terms of this License. > > d) If a facility in the modified Library refers to a function or a > table of data to be supplied by an application program that uses > the facility, other than as an argument passed when the facility > is invoked, then you must make a good faith effort to ensure that, > in the event an application does not supply such function or > table, the facility still operates, and performs whatever part of > its purpose remains meaningful. > > (For example, a function in a library to compute square roots has > a purpose that is entirely well-defined independent of the > application. Therefore, Subsection 2d requires that any > application-supplied function or table used by this function must > be optional: if the application does not supply it, the square > root function must still compute square roots.) > > These requirements apply to the modified work as a whole. If > identifiable sections of that work are not derived from the Library, > and can be reasonably considered independent and separate works in > themselves, then this License, and its terms, do not apply to those > sections when you distribute them as separate works. But when you > distribute the same sections as part of a whole which is a work based > on the Library, the distribution of the whole must be on the terms of > this License, whose permissions for other licensees extend to the > entire whole, and thus to each and every part regardless of who wrote > it. > > Thus, it is not the intent of this section to claim rights or contest > your rights to work written entirely by you; rather, the intent is to > exercise the right to control the distribution of derivative or > collective works based on the Library. > > In addition, mere aggregation of another work not based on the Library > with the Library (or with a work based on the Library) on a volume of > a storage or distribution medium does not bring the other work under > the scope of this License. > > 3. You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. To do > this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version 2, > instead of to this License. (If a newer version than version 2 of the > ordinary GNU General Public License has appeared, then you can specify > that version instead if you wish.) Do not make any other change in > these notices. > > Once this change is made in a given copy, it is irreversible for > that copy, so the ordinary GNU General Public License applies to all > subsequent copies and derivative works made from that copy. > > This option is useful when you wish to copy part of the code of > the Library into a program that is not a library. > > 4. You may copy and distribute the Library (or a portion or > derivative of it, under Section 2) in object code or executable form > under the terms of Sections 1 and 2 above provided that you accompany > it with the complete corresponding machine-readable source code, which > must be distributed under the terms of Sections 1 and 2 above on a > medium customarily used for software interchange. > > If distribution of object code is made by offering access to copy > from a designated place, then offering equivalent access to copy the > source code from the same place satisfies the requirement to > distribute the source code, even though third parties are not > compelled to copy the source along with the object code. > > 5. A program that contains no derivative of any portion of the > Library, but is designed to work with the Library by being compiled or > linked with it, is called a "work that uses the Library". Such a > work, in isolation, is not a derivative work of the Library, and > therefore falls outside the scope of this License. > > However, linking a "work that uses the Library" with the Library > creates an executable that is a derivative of the Library (because it > contains portions of the Library), rather than a "work that uses the > library". The executable is therefore covered by this License. > Section 6 states terms for distribution of such executables. > > When a "work that uses the Library" uses material from a header file > that is part of the Library, the object code for the work may be a > derivative work of the Library even though the source code is not. > Whether this is true is especially significant if the work can be > linked without the Library, or if the work is itself a library. The > threshold for this to be true is not precisely defined by law. > > If such an object file uses only numerical parameters, data > structure layouts and accessors, and small macros and small inline > functions (ten lines or less in length), then the use of the object > file is unrestricted, regardless of whether it is legally a derivative > work. (Executables containing this object code plus portions of the > Library will still fall under Section 6.) > > Otherwise, if the work is a derivative of the Library, you may > distribute the object code for the work under the terms of Section 6. > Any executables containing that work also fall under Section 6, > whether or not they are linked directly with the Library itself. > > 6. As an exception to the Sections above, you may also combine or > link a "work that uses the Library" with the Library to produce a > work containing portions of the Library, and distribute that work > under terms of your choice, provided that the terms permit > modification of the work for the customer's own use and reverse > engineering for debugging such modifications. > > You must give prominent notice with each copy of the work that the > Library is used in it and that the Library and its use are covered by > this License. You must supply a copy of this License. If the work > during execution displays copyright notices, you must include the > copyright notice for the Library among them, as well as a reference > directing the user to the copy of this License. Also, you must do one > of these things: > > a) Accompany the work with the complete corresponding > machine-readable source code for the Library including whatever > changes were used in the work (which must be distributed under > Sections 1 and 2 above); and, if the work is an executable linked > with the Library, with the complete machine-readable "work that > uses the Library", as object code and/or source code, so that the > user can modify the Library and then relink to produce a modified > executable containing the modified Library. (It is understood > that the user who changes the contents of definitions files in the > Library will not necessarily be able to recompile the application > to use the modified definitions.) > > b) Use a suitable shared library mechanism for linking with the > Library. A suitable mechanism is one that (1) uses at run time a > copy of the library already present on the user's computer system, > rather than copying library functions into the executable, and (2) > will operate properly with a modified version of the library, if > the user installs one, as long as the modified version is > interface-compatible with the version that the work was made with. > > c) Accompany the work with a written offer, valid for at > least three years, to give the same user the materials > specified in Subsection 6a, above, for a charge no more > than the cost of performing this distribution. > > d) If distribution of the work is made by offering access to copy > from a designated place, offer equivalent access to copy the above > specified materials from the same place. > > e) Verify that the user has already received a copy of these > materials or that you have already sent this user a copy. > > For an executable, the required form of the "work that uses the > Library" must include any data and utility programs needed for > reproducing the executable from it. However, as a special exception, > the materials to be distributed need not include anything that is > normally distributed (in either source or binary form) with the major > components (compiler, kernel, and so on) of the operating system on > which the executable runs, unless that component itself accompanies > the executable. > > It may happen that this requirement contradicts the license > restrictions of other proprietary libraries that do not normally > accompany the operating system. Such a contradiction means you cannot > use both them and the Library together in an executable that you > distribute. > > 7. You may place library facilities that are a work based on the > Library side-by-side in a single library together with other library > facilities not covered by this License, and distribute such a combined > library, provided that the separate distribution of the work based on > the Library and of the other library facilities is otherwise > permitted, and provided that you do these two things: > > a) Accompany the combined library with a copy of the same work > based on the Library, uncombined with any other library > facilities. This must be distributed under the terms of the > Sections above. > > b) Give prominent notice with the combined library of the fact > that part of it is a work based on the Library, and explaining > where to find the accompanying uncombined form of the same work. > > 8. You may not copy, modify, sublicense, link with, or distribute > the Library except as expressly provided under this License. Any > attempt otherwise to copy, modify, sublicense, link with, or > distribute the Library is void, and will automatically terminate your > rights under this License. However, parties who have received copies, > or rights, from you under this License will not have their licenses > terminated so long as such parties remain in full compliance. > > 9. You are not required to accept this License, since you have not > signed it. However, nothing else grants you permission to modify or > distribute the Library or its derivative works. These actions are > prohibited by law if you do not accept this License. Therefore, by > modifying or distributing the Library (or any work based on the > Library), you indicate your acceptance of this License to do so, and > all its terms and conditions for copying, distributing or modifying > the Library or works based on it. > > 10. Each time you redistribute the Library (or any work based on the > Library), the recipient automatically receives a license from the > original licensor to copy, distribute, link with or modify the Library > subject to these terms and conditions. You may not impose any further > restrictions on the recipients' exercise of the rights granted herein. > You are not responsible for enforcing compliance by third parties with > this License. > > 11. If, as a consequence of a court judgment or allegation of patent > infringement or for any other reason (not limited to patent issues), > conditions are imposed on you (whether by court order, agreement or > otherwise) that contradict the conditions of this License, they do not > excuse you from the conditions of this License. If you cannot > distribute so as to satisfy simultaneously your obligations under this > License and any other pertinent obligations, then as a consequence you > may not distribute the Library at all. For example, if a patent > license would not permit royalty-free redistribution of the Library by > all those who receive copies directly or indirectly through you, then > the only way you could satisfy both it and this License would be to > refrain entirely from distribution of the Library. > > If any portion of this section is held invalid or unenforceable under any > particular circumstance, the balance of the section is intended to apply, > and the section as a whole is intended to apply in other circumstances. > > It is not the purpose of this section to induce you to infringe any > patents or other property right claims or to contest validity of any > such claims; this section has the sole purpose of protecting the > integrity of the free software distribution system which is > implemented by public license practices. Many people have made > generous contributions to the wide range of software distributed > through that system in reliance on consistent application of that > system; it is up to the author/donor to decide if he or she is willing > to distribute software through any other system and a licensee cannot > impose that choice. > > This section is intended to make thoroughly clear what is believed to > be a consequence of the rest of this License. > > 12. If the distribution and/or use of the Library is restricted in > certain countries either by patents or by copyrighted interfaces, the > original copyright holder who places the Library under this License may add > an explicit geographical distribution limitation excluding those countries, > so that distribution is permitted only in or among countries not thus > excluded. In such case, this License incorporates the limitation as if > written in the body of this License. > > 13. The Free Software Foundation may publish revised and/or new > versions of the Lesser General Public License from time to time. > Such new versions will be similar in spirit to the present version, > but may differ in detail to address new problems or concerns. > > Each version is given a distinguishing version number. If the Library > specifies a version number of this License which applies to it and > "any later version", you have the option of following the terms and > conditions either of that version or of any later version published by > the Free Software Foundation. If the Library does not specify a > license version number, you may choose any version ever published by > the Free Software Foundation. > > 14. If you wish to incorporate parts of the Library into other free > programs whose distribution conditions are incompatible with these, > write to the author to ask for permission. For software which is > copyrighted by the Free Software Foundation, write to the Free > Software Foundation; we sometimes make exceptions for this. Our > decision will be guided by the two goals of preserving the free status > of all derivatives of our free software and of promoting the sharing > and reuse of software generally. > > NO WARRANTY > > 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO > WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. > EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR > OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY > KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE > IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE > LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME > THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. > > 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN > WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY > AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU > FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR > CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE > LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING > RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A > FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF > SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH > DAMAGES. > > END OF TERMS AND CONDITIONS > > How to Apply These Terms to Your New Libraries > > If you develop a new library, and you want it to be of the greatest > possible use to the public, we recommend making it free software that > everyone can redistribute and change. You can do so by permitting > redistribution under these terms (or, alternatively, under the terms of the > ordinary General Public License). > > To apply these terms, attach the following notices to the library. It is > safest to attach them to the start of each source file to most effectively > convey the exclusion of warranty; and each file should have at least the > "copyright" line and a pointer to where the full notice is found. > > > Copyright (C) > > This library is free software; you can redistribute it and/or > modify it under the terms of the GNU Lesser General Public > License as published by the Free Software Foundation; either > version 2.1 of the License, or (at your option) any later version. > > This library is distributed in the hope that it will be useful, > but WITHOUT ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > Lesser General Public License for more details. > > You should have received a copy of the GNU Lesser General Public > License along with this library; if not, write to the Free Software > Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > > Also add information on how to contact you by electronic and paper mail. > > You should also get your employer (if you work as a programmer) or your > school, if any, to sign a "copyright disclaimer" for the library, if > necessary. Here is a sample; alter the names: > > Yoyodyne, Inc., hereby disclaims all copyright interest in the > library `Frob' (a library for tweaking knobs) written by James Random Hacker. > > , 1 April 1990 > Ty Coon, President of Vice > > That's all there is to it! > ------------------------ end of proposed license ------------------ > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From gjhanna at gmail.com Sun Mar 11 14:21:17 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Mon, 12 Mar 2007 09:21:17 +1300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hi Pavel, We are using RXTX under VMWare server in production, quite satisfactorily. We're using Red Hat Enterprise Server 4, and ... Whatever the "enterprise" VMWare product is. Regards, Greg H > Subject: [Rxtx] RXTX under VMWare server > To: rxtx at qbang.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. [ ... snip ... ] -- Pavel Parkhomenko -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070311/4cebb6f9/attachment-0087.html From gergg at cox.net Sun Mar 11 23:39:19 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 12 Mar 2007 00:39:19 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: <45F4E787.6050502@cox.net> Trent Jarvi wrote: > I can start going through the method interfaces later this week and giving > feedback. I would suggest that the JSR should not be too generic in > nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel > drivers that intend to look like EIA232 ports at the kernel driver level. > > some ideas: > > EIA232PortInterface > TermiosInterface > SerialPortInterface > > Something that differentiates this from thing like USB, I2C, ... which > should not have to deal with legacy serial claiming to be the comm api. I'm going to throw out a suggestion, which I am mostly serious about. What would happen if we took the appropriate bits of the J2ME connector API, and just used that as the new COMM API so that finally JSE and JME had a common foundation for these kinds of things? Gregg Wonderly From ra85551 at gmail.com Mon Mar 12 09:08:37 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Mon, 12 Mar 2007 18:08:37 +0300 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Should any application use the modem, HyperTerminal won't be able to talk to the modem. But it actually can send and receive AT comands, while my application cannot :-( > Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Thansk for the reference. I examined that example and found that there's no significant differences between my read/write implementation and that one, except that SimpleSnuV1 listens for serialEvent's, but not for sake of data retrieval, just for printing them out - I don't know why ;-) > Note that modems could care less what OS is on top. If you are trying to > match new lines to the OS and sending it to the mode for AT commands, > thats probably a mistake. I do send strings to serial port, not to OS, and do try to get answers back. If it is the mistake, what's the right way? > Also it would not hurt to print out the > individual bytes that you are sending to make sure they did not get > mangled along the path. Yeah, I am printing these bytes before doing write, but it means that I only see what I intend to write. How can I ensure that these bytes have gone out of the box and reached my modem? BTW, I found that my send/receive method is complex enough, so I've rewritten it. Please, see the following code and point any mistakes, because I don't know where can they remain yet. private static final int LARGE_TIMEOUT = 15000; private static final int SMALL_TIMEOUT = 500; ... private String sendATCommand(String command, String waitFor, boolean isRegex, boolean isAddCRLF) throws BeaconConnectException { byte[] buffer = new byte[512]; int offset; String result = ""; try { if (waitFor != null) { serialPort.enableReceiveTimeout(LARGE_TIMEOUT); } else { serialPort.enableReceiveTimeout(SMALL_TIMEOUT); } if (command != null) { OutputStream serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } offset = 0; InputStream serialInput = serialPort.getInputStream(); while (serialInput.available() != -1) { int bytesRead = serialInput.read(buffer, offset, buffer.length - offset); if (bytesRead == 0) { break; } offset += bytesRead; result = new String(buffer, 0, offset).trim(); if (waitFor != null) { System.out.println(result); if (isRegex && result.matches(waitFor) || result.contains(waitFor)) { break; } } } } catch (UnsupportedCommOperationException e) { throw new MyException("unsupported operation"); } catch (IOException e) { throw new MytException("serial I/O error"); } return result; } -- Pavel Parkhomenko From clayno at hotpop.com Thu Mar 15 02:47:34 2007 From: clayno at hotpop.com (Christopher Layno) Date: Thu, 15 Mar 2007 16:47:34 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi, we're using the latest release of rxtx (2.1-7r2) for our system that has two applications using the library. one application sends requests to the modem while the other simply checks the modem status. we deployed our system on a pentium machine with red hat linux 9.0 installed. now the problem arises when these two applications try to access the same modem at the same time. one of them will eventually have to throw the PortInUseException as shown below: 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException gnu.io.PortInUseException: root PID = 743 Program = java root PID = 743 Program = java root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) this was expected. what we didn't expect though was that if we repeat the scenario 5 times, always 5 times, the application would also throw a VM error: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4473CD21 Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so Current Java thread: at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) - locked <0x44cfd4c8> (a gnu.io.CommPortIdentifier) at ************ at ************ - locked <0x4476a468> (a **********) at ************ at ************ at ************ at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java :261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages( TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run( TCPTransport.java:701) at java.lang.Thread.run(Thread.java:534) note: i replaced some sensitive data with asterisks our team has looked everywhere on the internet, including your mail archives, for a solution to this problem but to no avail. i really hope you could help us out on this one. thanks in advance! best regards, chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070315/1936460a/attachment-0084.html From tjarvi at qbang.org Fri Mar 16 04:30:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 04:30:25 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: On Thu, 15 Mar 2007, Christopher Layno wrote: > hi, > > we're using the latest release of rxtx (2.1-7r2) for our system that has two > applications using the library. one application sends requests to the modem > while the other simply checks the modem status. we deployed our system on a > pentium machine with red hat linux 9.0 installed. > > now the problem arises when these two applications try to access the same > modem at the same time. one of them will eventually have to throw the > PortInUseException as shown below: > > 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException > gnu.io.PortInUseException: root PID = 743 Program = java root PID = > 743 Program = java root PID = 743 Program = ??? root PID = 743 Program > = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root > PID = 743 Program = ??? root PID = 743 Program = ??? > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > > this was expected. what we didn't expect though was that if we repeat the > scenario 5 times, always 5 times, the application would also throw a VM > error: > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x4473CD21 > Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 > Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so > > Current Java thread: > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) Hi Chris The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. The code is originally by Werner Almesberger. He gave us permission to use it in rxtx. You might look at what has changed since 1998 in his fuser application. Or you can just do like other OSs and do the following in fuserImp.c JNIEXPORT jstring JNICALL Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv *env, jobject obj, jstring arg) { return (*env)->NewStringUTF(env, "Unknown Application"); } It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. -- Trent Jarvi tjarvi at qang.org From Adrien.TOS at ingenico.com Fri Mar 16 05:11:12 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Fri, 16 Mar 2007 12:11:12 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903CBC312@frsnprexc1.usr.ingenico.loc> Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070316/972ab214/attachment-0083.html From joachim at buechse.de Fri Mar 16 05:13:24 2007 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 16 Mar 2007 12:13:24 +0100 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. From tjarvi at qbang.org Fri Mar 16 16:36:29 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 16:36:29 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Fri Mar 16 16:02:23 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 16 Mar 2007 18:02:23 -0400 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Not all platforms are Unix based. Also mixing native library usage and command-line calls is not an elegant solution, IMHO. One or the other, but not both. Andre On 16-Mar-07, at 07:13 , Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is > trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We >> only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From clayno at hotpop.com Sun Mar 18 22:17:28 2007 From: clayno at hotpop.com (Christopher Layno) Date: Mon, 19 Mar 2007 12:17:28 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi everyone, thank you so much for your replies. they were really helpful. anyway, before i sent the email, my team was already implementing a temporary solution by using joachim's suggestion. we invoked a lsof command from our java code although i share the same concern with trent and andre-john about portability issues. that's why i said it's just temporary. my superiors have yet to approve our bug fix. so my question now is this: is recompiling the rxtx source code the only way to solve this problem? because if it's the only solution, then i think my superiors would rather have a new release from the rxtx community itself that fixes this bug(?) rather than have my team recompile the source code. best regards, chris Trent Jarvi wrote: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. ... It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070318/237463b2/attachment-0080.html From tjarvi at qbang.org Mon Mar 19 16:20:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Mar 2007 16:20:52 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: Hi Chris I can compile a new version after the 21st if you do not feel comfortable doing so. Please send me an email reminder off-line then. On Mon, 19 Mar 2007, Christopher Layno wrote: > hi everyone, > > thank you so much for your replies. they were really helpful. > > anyway, before i sent the email, my team was already implementing a > temporary solution by using joachim's suggestion. > we invoked a lsof command from our java code although i share the same > concern with trent and andre-john about > portability issues. that's why i said it's just temporary. my superiors have > yet to approve our bug fix. > > so my question now is this: is recompiling the rxtx source code the only way > to solve this problem? because if it's the only > solution, then i think my superiors would rather have a new release from the > rxtx community itself that fixes this bug(?) > rather than have my team recompile the source code. > > best regards, > > chris > > Trent Jarvi wrote: > > Hi Joachim > > It would be nice to have that functionality but calling the program > introduces too many issues imho. Explaining to someone why rxtx invoked a > rogue lsof does not sound very interesting. > > On Fri, 16 Mar 2007, Joachim Buechse wrote: > > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: > > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. > > _______________________________________________ > Rxtx mailing list > Rxtx 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 Eric.Arseneau at sun.com Tue Mar 20 11:47:33 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Tue, 20 Mar 2007 10:47:33 -0700 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 Message-ID: <46001E35.9040608@sun.com> Anyone have any experience with RXTX working with JDK 6 on other platforms ? From mm at UDel.Edu Tue Mar 20 12:18:29 2007 From: mm at UDel.Edu (Mike Markowski) Date: Tue, 20 Mar 2007 14:18:29 -0400 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 In-Reply-To: <46001E35.9040608@sun.com> References: <46001E35.9040608@sun.com> Message-ID: <46002575.4000306@udel.edu> Eric Arseneau wrote: > Anyone have any experience with RXTX working with JDK 6 on other platforms ? I'm using 32 bit intel, gentoo linux, jdk6 with no problems. My applications only use a serial port, though, nothing on the parallel port. Mike From falko.guderian at gmx.de Wed Mar 21 08:17:35 2007 From: falko.guderian at gmx.de (Falko Guderian) Date: Wed, 21 Mar 2007 15:17:35 +0100 Subject: [Rxtx] RXTX binaries for SH4 Message-ID: <46013E7F.40102@gmx.de> Dear developers, I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no possiblities to compile the source code. Better, I'm not able to do this at the moment. Can you provide me with rxtxSerial.dll (SH4) in the rxtx-2.1-8-testing version? (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) The reason for the testing version is I need custom baud rates. Thanks for help. Kind regards, Falko Guderian From tjarvi at qbang.org Wed Mar 21 21:38:37 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Mar 2007 21:38:37 -0600 (MDT) Subject: [Rxtx] RXTX binaries for SH4 In-Reply-To: <46013E7F.40102@gmx.de> References: <46013E7F.40102@gmx.de> Message-ID: On Wed, 21 Mar 2007, Falko Guderian wrote: > Dear developers, > > I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no > possiblities to compile the source code. Better, I'm not able to do this > at the moment. Can you provide me with rxtxSerial.dll (SH4) in the > rxtx-2.1-8-testing version? > (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) > > The reason for the testing version is I need custom baud rates. > > Thanks for help. > Hi Falko WinCE binary format is not supported by gcc. That makes compiling limited to those familiar with the WinCE tools. I hope someone is able to provide them for you but it is not likely. WinCE has been compiled by others in the past but rxtx.org builds have never included WinCE. There is some information with the source concerning WinCE builds if you decide to do it. We can share your results too if you like. The source in the WinCE has never been updated for the custom baud rate. That would need changes from the main source I presume. If you look at the source, you will note that Michal Hobot created a mini fork in the source to handle wince but it has not been updated for 3 years. -- Trent Jarvi tjarvi at qbang.org From Adrien.TOS at ingenico.com Thu Mar 22 07:08:55 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Thu, 22 Mar 2007 14:08:55 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Hi everybody, Do you have any comments on this issue? Thanks! AT ________________________________ De : Adrien TOS Envoy? : vendredi 16 mars 2007 12:11 ? : 'rxtx at qbang.org' Cc : Adrien TOS Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070322/2306c538/attachment-0076.html From jeremy.reeve at zen.co.uk Mon Mar 19 07:36:04 2007 From: jeremy.reeve at zen.co.uk (Jeremy S. Reeve) Date: Mon, 19 Mar 2007 13:36:04 +0000 Subject: [Rxtx] rxtx failing to compile on Fedora Core 6 Message-ID: <1174311364.21865.6.camel@d9thc> When trying to compile latest source : rxtx-2.1-7r2 I get the following when running configure: ---------------- checking os.version 2.6.18-1.2200.fc5smp WARNING: configure is having a hard time determining which directory contains the file jni_md.h. Edit Makefile and fix the variable JAVANATINC to point to the correct directory. The following options are available: /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/ /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/linux/ If there are more than one option available the first was selected. WARNING: Kernel include files do not match the current kernel configure: creating ./config.status ------------------------ which seems OK checking the resultant Makefile but when attempting to build with gmake install I get the following output : ---------------------- 34 problems (34 warnings)/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/javah -classpath .:/home/jsr/rxtxsrc/rxtx-2.1-7r2:/home/jsr/rxtxsrc/rxtx-2.1-7r2/src:/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/ext/RXTXcomm.jar -d i686-pc-linux-gnu -jni `(for i in CommDriver CommPortEnumerator CommPortIdentifier CommPort CommPortOwnershipListener Configure I2C I2CPortEvent I2CPortEventListener I2CPort LPRPort NoSuchPortException ParallelPortEvent ParallelPortEventListener ParallelPort PortInUseException Raw RawPortEvent RawPortEventListener RawPort RS485 RS485PortEvent RS485PortEventListener RS485Port RXTXCommDriver RXTXPort RXTXVersion SerialPortEvent SerialPortEventListener SerialPort UnsupportedCommOperationException UnSupportedLoggerException Zystem;do \ if grep > /dev/null native.* \( /home/jsr/rxtxsrc/rxtx-2.1-7r2/./src/$i.java; then \ echo gnu.io.$i; \ fi; \ done)` i686-pc-linux-gnu/gnu_io_CommPortIdentifier.h: No such file or directory make: *** [/home/jsr/rxtxsrc/rxtx-2.1-7r2/gnu/io/CommDriver.class] Error 1 ------------------------ Any ideas or pointers? Regards, Jeremy From tjarvi at qbang.org Sat Mar 24 08:12:54 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 Mar 2007 08:12:54 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > From Adrien.TOS at ingenico.com Sat Mar 24 11:53:22 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Sat, 24 Mar 2007 18:53:22 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> I do not have the threshold setting enabled, I have explicitely disabled it with: port_.disableReceiveThreshold(); I have also run the same tests with the threshold setting enabled, but they also fail in the same way as described below. So it seems there is a problem with timeout handling on Win32? ________________________________ From: rxtx-bounces at qbang.org on behalf of Trent Jarvi Sent: Sat 3/24/2007 3:12 PM To: RXTX Developers and Users Subject: Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 8312 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20070324/f9e39c9b/attachment-0074.bin From greg.johnson at manchester.ac.uk Sun Mar 25 13:41:36 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Sun, 25 Mar 2007 21:41:36 +0200 Subject: [Rxtx] Mac intel weirdness Message-ID: Hi folks, I'm trying to get rxtx to work on my macbook pro with a USB-serial dongle on it. I am using the 2.1-8 code from the CVS (though it seems to report itself as 2.1-7: makes it difficult to prove to oneself that the changes have 'taken'! - line 4210 in SerialImp.c, line 40 in RXTXVersion.java) I am trying the 2.1-8 because of horrible lock problems in 2.1-7. However, the serialport closure code seems to be broken - it won't close because it believes the (previously opened!) port doesn't exist. Here is what I'm trying: 0. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "false" 1. Open a port Serialport serialport = (SerialPort) commportidentifier.open ("test",100); 2. Talk to a device ... 3. Close port serialport.close(); 4. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "true" - why is this? 5. Try to reopen port Serialport serialport2 = (SerialPort) commportidentifier.open("test", 100); throws PortInUseException. I've dug around a bit in the source, and it seems the SerialPort.close () should call the CommPortIdentifier.internalClosePort() (line 67 of CommPort.java). However, I crash out with the NoSuchPortException when getPortIdentifier is called. Which seems quite weird to me, seeing as it is called on this - which was create just beforehand. Does anyone know how to fix this? Cheers, greg From knute at frazmtn.com Sat Mar 24 10:32:38 2007 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 24 Mar 2007 09:32:38 -0700 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc>, Message-ID: <4604F036.17833.135298@knute.frazmtn.com> > >The behavior of timeout depends upon the setting of the threshold. Do you >have the threshold setting? > This is the same bug I reported last fall. There was a fellow that sent me an email asking if it had been fixed. I told him I didn't think so. He got somebody to write a fix for him but I have not been able to contact him again for the actual changes. The inaccurate timeout and the failure of blocking when no timeouts are set is a serious bug in my humble opinion and renders the software unusable for my applications. I'd really like to have an alternative to the Sun comm api but there just isn't one that I know of. -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Mar 26 16:17:00 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 26 Mar 2007 16:17:00 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> Message-ID: >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. From ra85551 at gmail.com Tue Mar 27 10:18:36 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Tue, 27 Mar 2007 20:18:36 +0400 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Ultimately I found a solution. At first, that wasn't actually the VMWare + WinXP + RXTX issue, that was WinXP + RXTX issue. But on pure XP it sometimes workes, sometimes not, while under VMWare I had never seen my snippet working at all. SimpleSnuV1.java would not help me, because there is only one line I missed, and SimpleSnuV1.java also doesn't contain it! It is as follows: serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_OUT | SerialPort.FLOWCONTROL_RTSCTS_IN); Thank you for your attention. -- Pavel Parkhomenko From griff at op.pl Wed Mar 28 01:28:19 2007 From: griff at op.pl (griff@op.pl) Date: Wed, 28 Mar 2007 09:28:19 +0200 Subject: [Rxtx] No blocking read on Windows. Message-ID: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/5d07d571/attachment-0071.html -------------- next part -------------- Hi, I have problem that InputStram.read() (SerialPort)?returns -1 instead blocking and waiting for data. I found that this problem was ?known in 2005 : ? >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > >> Hi Trent >> >> Thanks for the fast response. >> Here's a Q&D test program for the blocking read on windows that just >> attempts to read one byte, and prints the resulting byte. On my system it >> returns -1, where I expect that it keeps waiting for data. >> >This isn't happening on Linux so the bug is in src/termios.c.? I'll have >something this weekend to fix that. I'm using RXTX 2.1.7r2 and the problem still is here. Im using Windows XP and java 1.5 disableReciveTimeout() and disableReciveTreshhold() dont help. ? best regards ? Piotr Zielniok From Adrien.TOS at ingenico.com Wed Mar 28 01:40:46 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Wed, 28 Mar 2007 09:40:46 +0200 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903E88880@frsnprexc1.usr.ingenico.loc> Looking at the code, it seems there is no support for infinite timeout? And maybe the count++ < 20 condition is breaking out of the loop too early? The only condition to break out of the loop should either be the timeout has expired or the number of requested bytes has been received. -----Message d'origine----- De : rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] De la part de Trent Jarvi Envoy? : mardi 27 mars 2007 00:17 ? : RXTX Developers and Users Objet : Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From j.kenneth.gentle at acm.org Wed Mar 28 06:44:15 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 28 Mar 2007 08:44:15 -0400 Subject: [Rxtx] No blocking read on Windows. In-Reply-To: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> References: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> Message-ID: <200703281844.l2SIiITW028614@qbang.org> Just another "ME TOO!" - I'm seeing this problem on Windows XP, jre for windows XP/Embedded. I cranked receiveTimeout up to Integer.MAX_INT, but it doesn't seem to wait that long At 03:28 2007-03-28, you wrote: >Hi, >I have problem that InputStram.read() (SerialPort) returns -1 >instead blocking and waiting for data. I found that this problem >was known in 2005 : > > >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > > > >> Hi Trent > >> > >> Thanks for the fast response. > >> Here's a Q&D test program for the blocking read on windows that just > >> attempts to read one byte, and prints the resulting byte. On my system it > >> returns -1, where I expect that it keeps waiting for data. > >> > > >This isn't happening on Linux so the bug is in src/termios.c. I'll have > >something this weekend to fix that. > >I'm using RXTX 2.1.7r2 and the problem still is here. >Im using Windows XP and java 1.5 >disableReciveTimeout() and disableReciveTreshhold() dont help. > >best regards > >Piotr Zielniok > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From greg.johnson at manchester.ac.uk Wed Mar 28 14:43:29 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Wed, 28 Mar 2007 22:43:29 +0200 Subject: [Rxtx] Cannot close and reopen serial port Message-ID: <377F9765-7A9D-4CE9-9176-FFB63A2594F0@manchester.ac.uk> Dear all, It appears I cannot close a port properly: SerialPort serialport = portid.open("myprog",100); // do some stuff, all works fine serialport.close(); // all seems fine but... SerialPort sp2 = portid.open("myprog",100); throws PortInUseException. And when I dig into the rxtx code, I find in CommPort.java, in close(): CommPortIdentifier cp = CommPortIdentifier.getPortIdentifier(this); (line 64 or there abouts) but this throws a NoSuchPortException which is caught but ignored (line 74ish). Can anyone suggest how this could happen: a port that was valid, opened, and used, throws a NSPE when it comes to closing it? I'm pulling my (remaining) hair out over this one! Cheers, greg PS And thanks for RXTX - it's great to have! PPS (21.-7. winxp/osx both, java 1.5) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/c28852fc/attachment-0070.html From rxtx at vrijheidslaan.net Fri Mar 30 16:52:50 2007 From: rxtx at vrijheidslaan.net (Rob) Date: Fri, 30 Mar 2007 22:52:50 -0000 Subject: [Rxtx] Cvs Question Message-ID: <61896.80.126.150.87.1175295162.squirrel@webmail.provalue.nl> Hi There, Im trying to get the latest version to work on mac osx. Problem is that i can't checkout version 2.1.8. Probably my fault but can some one please give me the alternative commands for: [user at myhost]$ export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot [user at myhost]$ cvs login Thanx, Rob From ra85551 at gmail.com Thu Mar 1 03:47:06 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Thu, 1 Mar 2007 13:47:06 +0300 Subject: [Rxtx] enableReceiveTimeout() issue Message-ID: Hello, world! I found a limitation of 16300 ms for CommPort's enableReceiveTimeout() method, while in original javax.comm docs there are no any references to that. Is that a bug or feature? I actually need longer timeouts sometimees. -- Pavel Parkhomenko From lyon at docjava.com Thu Mar 1 07:54:17 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 01 Mar 2007 09:54:17 -0500 Subject: [Rxtx] parametric singleton design pattern In-Reply-To: References: <22d55aea0702081207q5e7f6785l352d498d6f5f9fb1@mail.gmail.com> <22d55aea0702100034o3bcf42f3j1d1a6257029a67b0@mail.gmail.com> Message-ID: Hi All, I have been thinking about the use of a design pattern to cache resources that are consumed by processes. Toward that end, I have arrived at a parametric singleton design pattern, which I mentioned on this list some time ago. The idea has been published at: http://www.jot.fm/issues/issue_2007_03/column2 I can't help but think that there should be an API available for dealing with the tracking of serial port usage. Perhaps it is a kind of resource manager called the: SerialPortManager basic prototypes already exist in this vain. See, for example: http://www.ce.rit.edu/research/projects/2005_fall/rt_poolsystem/doc/PoolMon/SerialPortManager.html http://www.eventhelix.com/RealtimeMantra/PatternCatalog/serial_port_design_pattern.htm And others shown by a google search on "SerialPortManager" Cheers! - Doug From Eric.Arseneau at sun.com Thu Mar 1 10:15:03 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:15:03 -0800 Subject: [Rxtx] Any known Java 6 issues with RXTX 2.1-7r2 ? Message-ID: <45E70A17.1060206@sun.com> I just did a test on a recent build of Solaris 11 x86 and it seems that I can connect to my serial device fine when Java 5 is the default, but when Java 6 is the default, no go. Any information ? From Eric.Arseneau at sun.com Thu Mar 1 10:19:58 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:19:58 -0800 Subject: [Rxtx] Mac OS X and missing data Message-ID: <45E70B3E.7040908@sun.com> We have a device which is USB based but presents itself as a serial port to a machine. On my MacBook Pro I can get excellent throughput if I get my device to send data as quickly as possible. On the desktop side, if I do an type of disk IO to log the data I get, I end up with some missing data at some point. I hooked up a USB analyzer and did confirm that all the data is sent as expected to the desktop from the device. I found a work around for this, buffer the data in memory and only write the data out when I've received it all. However, when the same code and same device is attempted on a co-workers MacBook Pro (same hardware specs), I get errors and must slow down dramatically the device side's sending of data. Any ideas/recommendations on what I can do to get rid of this error ? From what I can tell, it seems that RXTX is not able to wake up to the interrupts coming in indicating data is ready, quickly enough, is there anything I can do ? From chinkaiw at hotmail.com Fri Mar 2 00:57:43 2007 From: chinkaiw at hotmail.com (Wang Chinkai) Date: Fri, 02 Mar 2007 07:57:43 +0000 Subject: [Rxtx] dynamic detect rs232 port Message-ID: Hi all I have a question about detecting rs232 port dynamicly. I have to aceess some port and detect rs232 port at the same time. Some usb device simulates rs232 port , and I can not know what the port name it gets until it connects,so I have to detect it dynamic,but I have to access another rs232 device at the same time. I found a problem. If I use CommPortIdentifier.getPortIdentifiers() to get new port list , and the other rs232 access function will not close port correctly. So , How can I solve it . Thanks. _________________________________________________________________ ?? 2GB ???? Windows Live Mail ????????????? http://ideas.live.com/programpage.aspx?versionid=5d21c51a-b161-4314-9b0e-4911fb2b2e6d From eu259473 at tele2.it Fri Mar 2 06:16:40 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 02 Mar 2007 14:16:40 +0100 Subject: [Rxtx] rxtx on HP tru 64 unix Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070302/706c7a70/attachment.html From tjarvi at qbang.org Fri Mar 2 08:39:33 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 08:39:33 -0700 (MST) Subject: [Rxtx] rxtx on HP tru 64 unix In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, "Giuseppe Marchese" wrote: > Hi > > I try to install rxtx on hp tru 64 but make fails, > There are somebody that do the same and work. > > > Sorry for may english! > > Hi Giuseppe Could you provide a log of the failure? script ./configure make # use gnu make exit The information will be in the typescript created. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 2 19:56:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 19:56:52 -0700 (MST) Subject: [Rxtx] dynamic detect rs232 port In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, Wang Chinkai wrote: > Hi all > > I have a question about detecting rs232 port dynamicly. > > I have to aceess some port and detect rs232 port at the same time. > Some usb device simulates rs232 port , and I can not know > what the port name it gets until it connects,so I have to detect it > dynamic,but I have to access > another rs232 device at the same time. > > I found a problem. Hi Wang This is a known problem. The code is braindead there. In fact there needs to be events even in a rudamentary way when you add a usb dongle. I'm burried in tasks not far from rxtx but not in rxtx. I can't get to the problem but we would accept patches if you dig into it. [I'm getting to the license question earlier too; I don't have another 10%] -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Fri Mar 2 23:19:01 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 01:19:01 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Hi, Under ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable USB -> serial converter(using virtual com port drivers), with using example code pretty much straight out of http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port opens fine, enumerations all work, etc. My application calls for a large amount of data to be transferred in a short amount of time at 2,000,000 baud. My hardware sends approximately 15,232 bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL converter work fine, and the application works using C++. In C++, I do a hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); to open the port, and a boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); to read the port. The variable buffer fills with the 15238 bytes, and returns. If I do a resultz = is.read(cbuf,0,15238); in java with RXTX where is = new BufferedReader(new InputStreamReader(port.getInputStream())); and where resultz is an int, and cbuf is a char [] cbuf, resultz gets EXACTLY 3968 bytes the first time called. If I call it multiple times, I get roughly 11k total(less than what is sent), never more than the 3968 bytes per is.read() call. My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 bytes. I've played with inputbuffersize, receive threshold, receivetimeout, and so on. The FTDI virtual com port drivers that I'm using are rock solid, and have had zero problems with them using a variety of applications, some of my own, some professionally written, etc. No flow control is used anyplace, no RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. No exceptions are being thrown. What am I doing wrong, and what I can adjust to receive the full 15k bytes in one single read? Thanks! Keith From Eric.Arseneau at sun.com Fri Mar 2 23:32:07 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Fri, 02 Mar 2007 22:32:07 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <45E91667.20501@sun.com> This is the same type of thing that is happening to me on Mac OS X and does not seem to behave the same on different machines. I posted a day or two ago on this with subject "Mac OS X and missing data". Would love to hear if there is a solution to this :) From tjarvi at qbang.org Sat Mar 3 10:54:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 10:54:17 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > Hi, > > Under > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable > USB -> serial converter(using virtual com port drivers), with using example > code pretty much straight out of > http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port > opens fine, enumerations all work, etc. > > My application calls for a large amount of data to be transferred in a short > amount of time at 2,000,000 baud. My hardware sends approximately 15,232 > bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL > converter work fine, and the application works using C++. > > In C++, I do a > > hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, > OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); > > to open the port, and a > > boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); > > to read the port. > > The variable buffer fills with the 15238 bytes, and returns. > > If I do a > > resultz = is.read(cbuf,0,15238); in java with RXTX > > where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > > and where resultz is an int, and cbuf is a char [] cbuf, resultz gets > EXACTLY 3968 bytes the first time called. If I call it multiple times, I get > roughly 11k total(less than what is sent), never more than the 3968 bytes > per is.read() call. > > My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 > bytes. > > I've played with inputbuffersize, receive threshold, receivetimeout, and so > on. The FTDI virtual com port drivers that I'm using are rock solid, and > have had zero problems with them using a variety of applications, some of my > own, some professionally written, etc. No flow control is used anyplace, no > RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. > > No exceptions are being thrown. > > What am I doing wrong, and what I can adjust to receive the full 15k bytes > in one single read? > > Thanks! > Hi Keith I would expect a 20 meg application is going to have different behavior with the OS than a smaller application with respect to the kernel memory managment, schedualing, ... Something subtle could be causing problems. With respect to the recieve timeout and threshold, if you set the timeout to zero and the threshold to the size of data you expect, read should not return until it get that data. You may try with a stand alone application that tests just that with the C/C++ API. If the read is returning with less data when tested for short reads, you have found a bug in the device driver more than likely. The USB dongle vendor would probably be interested in knowing about this. As mentioned, these devices are getting very good; almost bug free. I suspect you found a bug though if you did use the threshold and timeout properly. The missing data is typical when not using flow control. When the OS buffering fills, the hardware will start dropping bytes. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:38:52 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:38:52 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> update: I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now instead of 3968. This makes sense. 128 bytes of overhead + 3968 bytes of data = 4096 transfer size 32 bytes of overhead + 992 bytes of data = 1024 transfer size. 1/4 the data = 1/4 the overhead. I rearranged my reading like so: resultz = is.read(cbuf,0,3968); resultz = is.read(cbuf,3968,3968); resultz = is.read(cbuf,7936,3968); while (!(is.ready())); // wait for ready resultz = is.read(cbuf,11904,3334); and this grabs 15,238 bytes total. BUT, I still have the quandry of the screwed up multi-bytes. I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. Approx 8% of the data. The bad bytes always seem to take the flavor of 0x2018, 0x2019, x2022, x2030, x201d. Are these maybe errors and I don't know what they enumerate to? I still can't believe some other layer isn't handling putting those bytes together all in one stream for me. Thanks Keith ----- Original Message ----- From: "Keith" To: "Bob Jacobsen" ; "RXTX Developers and Users" Sent: Saturday, March 03, 2007 11:26 AM Subject: Re: [Rxtx] is.read() only returning 3968 bytes > Bob, > > > Interesting numerical coincidence is that (max USB transfer) - (what > > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > > needed to transfer that much data. > > I was thinking along the same lines. I don't know USB well, but I do know > that those numbers were close enough to warrant investigating the > relationship between them. > > > I think what you're seeing is the internal buffering of the USB data > > stream. You'll need some form of higher-level buffering to smooth > > that out. > > Shouldn't the InputStreamReader() and BufferedReader() provide this type of > buffering? Isn't that the idea behind those? > > > All hypotheses need to be tested. In this case, a test would be to > > check for missing data. If this idea is right, you'll get _all_ the > > data, but you won't be missing characters. > > I did start looking at the data. -- I'm getting weird results. > > I tried this: > > loopzz = 0; > > for (looptwo = 0; looptwo < 100000; looptwo++) { > while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > > }} > > So I'm reading one character at a time. The good news is that loopzz is > exactly 15238 at the end of the routine, which is perfectly correct. I > picked looptwo value out of thin air. > > The weird results come in terms of the values, the data isn't correct at > least in one case. Look here: > > 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > > This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). > But the 0x89 was replaced by 0x2030. Why the heck would the returned value > be 0x2030?? Why is the returned byte completely out of range? Why the > multibyte return? > > From InputStream in the API: > > read > public abstract int read() > throws IOExceptionReads the next byte of data from the > input stream. The value byte is returned as an int in the range 0 to 255. If > no byte is available because the end of the stream has been reached, the > value -1 is returned. This method blocks until input data is available, the > end of the stream is detected, or an exception is thrown. > Value should be 0-255. > > > In my application time is really critical, reading 1 byte at a time is > probably not going to work. > > Thanks Eric & Bob for looking at this. > > Keith > From tjarvi at qbang.org Sat Mar 3 12:52:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 12:52:27 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > update: > > I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now > instead of 3968. > > This makes sense. > > 128 bytes of overhead + 3968 bytes of data = 4096 transfer size > 32 bytes of overhead + 992 bytes of data = 1024 transfer size. > > 1/4 the data = 1/4 the overhead. > > I rearranged my reading like so: > > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. > Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? > > I still can't believe some other layer isn't handling putting those bytes > together all in one stream for me. > The layer for this in Serial land is flow control. Software and hardware flow control prevent the overruns you observe. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:54:41 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:54:41 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <001a01c75dcd$c8802a70$6600a8c0@jbh757ktruws7g> Trent, Thanks for taking the time to reply. > I would expect a 20 meg application is going to have different behavior > with the OS than a smaller application with respect to the kernel memory > managment, schedualing, ... Something subtle could be causing problems. Well, at least I know the VCP drivers, the OS, etc can handle 2mbps reliably. Without hiccuping or dropping bytes. The C++ code works reliably without flow control. > The missing data is typical when not using flow control. When the OS > buffering fills, the hardware will start dropping bytes. I'm actually not getting MISSING data, I'm getting CORRUPTED data. If you look at my most recent post, I'm getting these bad bytes in place of the correct values: 0x2018, 0x2019, x2022, x2030, x201d. Why would is.read() return values not in the range of 0-255 ? Thanks. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 08:59:14 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 07:59:14 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: At 1:19 AM -0500 3/3/07, Keith wrote: >If I do a > >resultz = is.read(cbuf,0,15238); in java with RXTX > >where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > >and where resultz is an int, and cbuf is a char [] cbuf, resultz gets >EXACTLY 3968 bytes the first time called. If I call it multiple times, I get >roughly 11k total(less than what is sent), never more than the 3968 bytes >per is.read() call. > >My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 >bytes. Interesting numerical coincidence is that (max USB transfer) - (what you get) = 4096-3968 = 128 bytes is (almost) the size of the headers needed to transfer that much data. I think what you're seeing is the internal buffering of the USB data stream. You'll need some form of higher-level buffering to smooth that out. All hypotheses need to be tested. In this case, a test would be to check for missing data. If this idea is right, you'll get _all_ the data, but you won't be missing characters. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 09:26:14 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 11:26:14 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Bob, > Interesting numerical coincidence is that (max USB transfer) - (what > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > needed to transfer that much data. I was thinking along the same lines. I don't know USB well, but I do know that those numbers were close enough to warrant investigating the relationship between them. > I think what you're seeing is the internal buffering of the USB data > stream. You'll need some form of higher-level buffering to smooth > that out. Shouldn't the InputStreamReader() and BufferedReader() provide this type of buffering? Isn't that the idea behind those? > All hypotheses need to be tested. In this case, a test would be to > check for missing data. If this idea is right, you'll get _all_ the > data, but you won't be missing characters. I did start looking at the data. -- I'm getting weird results. I tried this: loopzz = 0; for (looptwo = 0; looptwo < 100000; looptwo++) { while (is.ready()) { cbuf[loopzz] = (char) is.read(); loopzz++; }} So I'm reading one character at a time. The good news is that loopzz is exactly 15238 at the end of the routine, which is perfectly correct. I picked looptwo value out of thin air. The weird results come in terms of the values, the data isn't correct at least in one case. Look here: 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). But the 0x89 was replaced by 0x2030. Why the heck would the returned value be 0x2030?? Why is the returned byte completely out of range? Why the multibyte return? >From InputStream in the API: read public abstract int read() throws IOExceptionReads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown. Value should be 0-255. In my application time is really critical, reading 1 byte at a time is probably not going to work. Thanks Eric & Bob for looking at this. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 14:44:50 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 13:44:50 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: Java's "char" type is Unicode. I think what you're seeing is a bug in the byte -> Unicode translation. 0x2018, 0x2019 are the curly open and close quotes. There used to be (and might still be) bugs in the conversion of these in a couple of libc versions. Some of the ASCII -> ISO and ISO -> ASCII routines were a little over-ambitious with respect to handling the open and close quotes, and tried to convert them to the "curly" form inappropriately. Try _not_ casting it to char. Bob At 11:26 AM -0500 3/3/07, Keith wrote: >Bob, > >> Interesting numerical coincidence is that (max USB transfer) - (what >> you get) = 4096-3968 = 128 bytes is (almost) the size of the headers >> needed to transfer that much data. > >I was thinking along the same lines. I don't know USB well, but I do know >that those numbers were close enough to warrant investigating the >relationship between them. > >> I think what you're seeing is the internal buffering of the USB data >> stream. You'll need some form of higher-level buffering to smooth >> that out. > >Shouldn't the InputStreamReader() and BufferedReader() provide this type of >buffering? Isn't that the idea behind those? > >> All hypotheses need to be tested. In this case, a test would be to >> check for missing data. If this idea is right, you'll get _all_ the >> data, but you won't be missing characters. > >I did start looking at the data. -- I'm getting weird results. > >I tried this: > >loopzz = 0; > >for (looptwo = 0; looptwo < 100000; looptwo++) { >while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > >}} > >So I'm reading one character at a time. The good news is that loopzz is >exactly 15238 at the end of the routine, which is perfectly correct. I >picked looptwo value out of thin air. > >The weird results come in terms of the values, the data isn't correct at >least in one case. Look here: > >0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > >This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). >But the 0x89 was replaced by 0x2030. Why the heck would the returned value >be 0x2030?? Why is the returned byte completely out of range? Why the >multibyte return? > >>From InputStream in the API: > >read >public abstract int read() > throws IOExceptionReads the next byte of data from the >input stream. The value byte is returned as an int in the range 0 to 255. If >no byte is available because the end of the stream has been reached, the >value -1 is returned. This method blocks until input data is available, the >end of the stream is detected, or an exception is thrown. >Value should be 0-255. > > >In my application time is really critical, reading 1 byte at a time is >probably not going to work. > >Thanks Eric & Bob for looking at this. > >Keith > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 15:10:11 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 17:10:11 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Bob said ..... > Java's "char" type is Unicode. I think what you're seeing is a bug > in the byte -> Unicode translation. Bob -- I think you hit the nail on the head. I was just coming to the same realization here. I knew that something funny was going on because the same bytes always got "corrupted." I'm pretty sure its in the InputStreamReader() functionality where the conversion junk is happening. Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. I don't know if simply changing the cast is going to work. Since the conversion is happening upstream (pun intended), I don't think my cast is doing this. Also I think the compiler forced me to use the cast. I'm still playing around, and I'll report back once I nail it down. Thanks!! Keith From tjarvi at qbang.org Sat Mar 3 15:59:46 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 15:59:46 -0700 (MST) Subject: [Rxtx] Win64 rxtx Testers? Message-ID: I have compiled win64 binaries of rxtx. Are there any users interested in testing them? If so, I'll look into putting them on the web site. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Mar 3 15:35:06 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 14:35:06 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: Because of this and similar problems, JMRI does all it's serial IO using +only+ byte values. It's a but of a pain, as Java wants to go to char and int types a little too aggressively, but it does solve the "uncontrolled conversions" problems. Bob At 5:10 PM -0500 3/3/07, Keith wrote: >Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > >Bob -- I think you hit the nail on the head. > >I was just coming to the same realization here. I knew that something funny >was going on because the same bytes always got "corrupted." > >I'm pretty sure its in the InputStreamReader() functionality where the >conversion junk is happening. > >Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > >I don't know if simply changing the cast is going to work. Since the >conversion is happening upstream (pun intended), I don't think my cast is >doing this. Also I think the compiler forced me to use the cast. -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mark at mdsh.com Sun Mar 4 11:01:33 2007 From: mark at mdsh.com (Mark Himsley) Date: Sun, 04 Mar 2007 18:01:33 +0000 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: <5C01AC72C200388815C04982@bedroom.mdsh.local> On 03 March 2007 14:38 -0500 Keith wrote: > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT > consistent. Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? It looks like you need to use DataInputStream and DataOutputStream. -- Mark Himsley From tjarvi at qbang.org Sun Mar 4 11:35:08 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 11:35:08 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" > > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > > * Line #21 - Not sure if you need a (TM) mark for > the term "Sun" > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > OK. I'm going through this today. Some groups ask if rxtx could be under their license also. I think this is a good example of why I resist multiple licenses and focus on why the current license may not be usable by them. The RXTX project is a convergence of hobby and commercial interests. I happen to do both right now. The problem with licensing is we have to stay on top of them as they change. Clearly, adding more licenses will not make this easier. I'm acting as the hobby person today. RXTX always favors the hobby people. But as we move forward, I'm going to need to bring this to lawyers at work and explain to them what is going on. Others here may have to do this also. I don't anticipate problems or unexpected changes. The goal is a consistant, comprehendable and usable license as close to what we have now as possible. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 14:52:10 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 14:52:10 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (1/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: I'm breaking this into two parts. I expect the second part will need more attention. Comments first, then the changed material below. On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > Thanks > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. OK. RXTX for consitent use. java should not be capitalized because it does not only mean Sun [TM] Java [TM]. An example of this not meaning Java is when people use RXTX with GCJ. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". There are not any contributors that are in all of RXTX yet but I did update the comment to try to reflect the current situation without making it a nightmare to maintain. I looked to see how the Linux kernel does it as a reference point. > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" The URL can be problematic. I have done so below with a time reference. GNU does not provide version information in their URLS. I picture this being a problem when the version 3 comes out. > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > This will be corrected when the copy is updated to the version linked below. ---------------- begin proposed material involved -------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. ----------------- end proposed material involved -------------------- I'll be looking at the linking issue again next. That should be all that remains other than including the 2.1 version. Let me know if you have problems with anything here. I do not want to dilute the material I post next with these housekeeping tasks. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 16:08:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 16:08:36 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: For those that are wondering what is going on here, this next bit is the meat of the changes. We agreed a long time ago to put this disclaimer in. We did a so so job. It was in rxtx 2.0, not well written, ... So some groups using rxtx that would like to ship rxtx so users don't need to download, install, go to the mail-list to find why it failed, ... Then their legal teams tell them section 5 paragraph 2 is a show stopper. That was never the intent. Now going through what remains... > and might need a (TM) suffix to make Sun happy. Added disclaimer at the ended 'all trademarks belong...' > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. OK. As you can see I was trying to adjust GNU text there for the LGPL. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. used dynamically linked terminology. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". I tried to address this more upfront with an intent statement. Let me know if you have problems with it. I also tried to make it a little more clear what was derived from the GNU solution by moving the link location closer to GNU's suggestion. > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > Thats the intent. Here is the combined fixes. Note that only the material in /*-- --*/ is being touched. The new GPL license is there but unmodified. ------------------------ begin proposed new license ------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. | | An executable that contains no derivative of any portion of RXTX, but | is designed to work with RXTX by being dynamically linked with it, | is considered a "work that uses the Library" subject to the terms and | conditions of the GNU Lesser General Public License. | | The following has been added to the RXTX License to remove | any confusion about linking to RXTX. We want to allow in part what | section 5, paragraph 2 of the LGPL does not permit in the special | case of linking over a controlled interface. The intent is to add a | Java Specification Request or standards body defined interface in the | future as another exception but one is not currently available. | | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface | | As a special exception, the copyright holders of RXTX give you | permission to link RXTX with independent modules that communicate with | RXTX solely through the Sun Microsytems CommAPI interface version 2, | regardless of the license terms of these independent modules, and to copy | and distribute the resulting combined work under terms of your choice, | provided that every copy of the combined work is accompanied by a complete | copy of the source code of RXTX (the version of RXTX used to produce the | combined work), being distributed under the terms of the GNU Lesser General | Public License plus this exception. An independent module is a | module which is not derived from or based on RXTX. | | Note that people who make modified versions of RXTX are not obligated | to grant this special exception for their modified versions; it is | their choice whether to do so. The GNU Lesser General Public License | gives permission to release a modified version without this exception; this | exception also makes it possible to release a modified version which | carries forward this exception. | | You should have received a copy of the GNU Lesser General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA | All trademarks belong to their respective owners. --------------------------------------------------------------------------*/ The original GNU Lesser General Public License Follows. GNU LESSER GENERAL PUBLIC LICENSE Version 2.1, February 1999 Copyright (C) 1991, 1999 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. [This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence the version number 2.1.] Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This license, the Lesser General Public License, applies to some specially designated software packages--typically libraries--of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below. When we speak of free software, we are referring to freedom of use, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish); that you receive source code or can get it if you want it; that you can change the software and use pieces of it in new free programs; and that you are informed that you can do these things. To protect your rights, we need to make restrictions that forbid distributors to deny you these rights or to ask you to surrender these rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library or if you modify it. For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights. We protect your rights with a two-step method: (1) we copyright the library, and (2) we offer you this license, which gives you legal permission to copy, distribute and/or modify the library. To protect each distributor, we want to make it very clear that there is no warranty for the free library. Also, if the library is modified by someone else and passed on, the recipients should know that what they have is not the original version, so that the original author's reputation will not be affected by problems that might be introduced by others. Finally, software patents pose a constant threat to the existence of any free program. We wish to make sure that a company cannot effectively restrict the users of a free program by obtaining a restrictive license from a patent holder. Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license. Most GNU software, including some libraries, is covered by the ordinary GNU General Public License. This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs. When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library. We call this license the "Lesser" General Public License because it does Less to protect the user's freedom than the ordinary General Public License. It also provides other free software developers Less of an advantage over competing non-free programs. These disadvantages are the reason we use the ordinary General Public License for many libraries. However, the Lesser license provides advantages in certain special circumstances. For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License. In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software. For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU operating system, as well as its variant, the GNU/Linux operating system. Although the Lesser General Public License is Less protective of the users' freedom, it does ensure that the user of a program that is linked with the Library has the freedom and the wherewithal to run that program using a modified version of the Library. The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, whereas the latter must be combined with the library in order to run. GNU LESSER GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License Agreement applies to any software library or other program which contains a notice placed by the copyright holder or other authorized party saying it may be distributed under the terms of this Lesser General Public License (also called "this License"). Each licensee is addressed as "you". A "library" means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables. The "Library", below, refers to any such software library or work which has been distributed under these terms. A "work based on the Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term "modification".) "Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library. Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does. 1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) The modified work must itself be a software library. b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change. c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License. d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful. (For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library. In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. 4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange. If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code. 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables. When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law. If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.) Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself. 6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications. You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things: a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.) b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. c) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution. d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place. e) Verify that the user has already received a copy of these materials or that you have already sent this user a copy. For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute. 7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things: a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above. b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work. 8. You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 9. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Library (or any work based on the Library), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Library or works based on it. 10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties with this License. 11. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply, and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 12. If the distribution and/or use of the Library is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Library under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 13. The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation. 14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Libraries If you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the ordinary General Public License). To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Also add information on how to contact you by electronic and paper mail. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the library, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the library `Frob' (a library for tweaking knobs) written by James Random Hacker. , 1 April 1990 Ty Coon, President of Vice That's all there is to it! ------------------------ end of proposed license ------------------ -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sun Mar 4 16:26:04 2007 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 04 Mar 2007 17:26:04 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <45EB558C.3010609@cox.net> Bob Jacobsen wrote: > Because of this and similar problems, JMRI does all it's serial IO > using +only+ byte values. It's a but of a pain, as Java wants to go > to char and int types a little too aggressively, but it does solve > the "uncontrolled conversions" problems. Anytime that you are reading bytes of data that is not printable, unicode text, in Java, you really need to stay away from the Readers. Use input stream only, or you will see unicode valued byte groups converted to unicode "char" values. Gregg Wonderly From joachim at buechse.de Mon Mar 5 04:23:48 2007 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 5 Mar 2007 12:23:48 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> The behaviour is exactly what you asked for in you code. is = new BufferedReader(new InputStreamReader(port.getInputStream())); Readers return Text (ie unicode chars) not bytes. You instantiate the InputStreamReader without saying which charset you want, which means "platform default". As this is on Windows, it will convert Windows characters to equivalent unicode characters. If you want to read bytes, read bytes not Text. Reading bytes is done with InputStream and BufferedInputStream. BTW: The InputStream and Reader methods that read arrays are not guarenteed to fill up the array. You always have to check what you really got, and advance your index accordingly. A typical "read up to 32k" method looks like this: InputStream is= ... // -- determine the max buffer size int len= is.available(); if (len == 0) { len= 32 * 1024; } // -- read all available data byte[] buffer= new byte[len]; int pos= 0; int read; do { read= is.read(buffer, pos, buffer.length - pos); pos= pos + read; } while (read != -1 && pos < buffer.length); Best regards, Joachim --- Joachim B?chse Phone: +41 44 500 2604 Buechse Consulting Hadlaubsteig 2 CH-8006 Z?rich On 03.03.2007, at 23:10, Keith wrote: > Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > > Bob -- I think you hit the nail on the head. > > I was just coming to the same realization here. I knew that > something funny > was going on because the same bytes always got "corrupted." > > I'm pretty sure its in the InputStreamReader() functionality where the > conversion junk is happening. > > Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > > I don't know if simply changing the cast is going to work. Since the > conversion is happening upstream (pun intended), I don't think my > cast is > doing this. Also I think the compiler forced me to use the cast. > > I'm still playing around, and I'll report back once I nail it down. > > Thanks!! > > Keith > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Mon Mar 5 07:25:46 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 05 Mar 2007 08:25:46 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> Message-ID: <45EC286A.8060608@cox.net> Joachim Buechse wrote: > BTW: The InputStream and Reader methods that read arrays are not > guarenteed to fill up the array. You always have to check what you > really got, and advance your index accordingly. A typical "read up to > 32k" method looks like this: > > InputStream is= ... > // -- determine the max buffer size > int len= is.available(); > if (len == 0) { > len= 32 * 1024; > } > // -- read all available data > byte[] buffer= new byte[len]; > int pos= 0; > int read; > do { > read= is.read(buffer, pos, buffer.length - pos); > pos= pos + read; > } while (read != -1 && pos < buffer.length); > My preferred structure is. byte arr[ len ]; int cnt; int off = 0; while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { off += cnt; } This keeps you from adding -1 to pos when the read returns -1. It also skips out when the read is 0 bytes which, is not a described EOF in InputStream java docs, but is a condition I want to be aware of. Gregg Wonderly From joachim at buechse.de Tue Mar 6 02:52:58 2007 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 6 Mar 2007 10:52:58 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <45EC286A.8060608@cox.net> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: The code I copied was from a file resource reader, it shouldn't really be applied to networking/external IO code. Mea culpa. However aborting when you get 0 from read is not always what you want either (you kind of indicated that already). Some unix java implementations will return 0 if the kernel read was aborted with EINTER, which is rarely the point where you want to abort your read - at least not without further checks. A "complete" solution always depends on the events you need to handle and the time the total read could take in reality. In some cases it's worth checking Thread.isInterrupted() in the loop, some code re-loops on 0 but only a limited number of times, some check a total timeout limit, etc... Best regards, Joachim On 05.03.2007, at 15:25, Gregg Wonderly wrote: > My preferred structure is. > > byte arr[ len ]; > int cnt; > int off = 0; > while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { > off += cnt; > } > > This keeps you from adding -1 to pos when the read returns -1. It > also skips > out when the read is 0 bytes which, is not a described EOF in > InputStream java > docs, but is a condition I want to be aware of. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Mar 6 14:47:44 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 Mar 2007 14:47:44 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: Just FYI, rxtx will usually not break out on EINTER. The code in the native library usually does something close to this: do { read(...) } while ( !done && errno==EINTR ); Obviously there is a little more involved but it will retry on EINTER if not done. On Tue, 6 Mar 2007, Joachim Buechse wrote: > The code I copied was from a file resource reader, it shouldn't > really be applied to networking/external IO code. Mea culpa. > > However aborting when you get 0 from read is not always what you want > either (you kind of indicated that already). Some unix java > implementations will return 0 if the kernel read was aborted with > EINTER, which is rarely the point where you want to abort your read - > at least not without further checks. A "complete" solution always > depends on the events you need to handle and the time the total read > could take in reality. In some cases it's worth checking > Thread.isInterrupted() in the loop, some code re-loops on 0 but only > a limited number of times, some check a total timeout limit, etc... > > Best regards, > Joachim > > On 05.03.2007, at 15:25, Gregg Wonderly wrote: >> My preferred structure is. >> >> byte arr[ len ]; >> int cnt; >> int off = 0; >> while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { >> off += cnt; >> } >> >> This keeps you from adding -1 to pos when the read returns -1. It >> also skips >> out when the read is 0 bytes which, is not a described EOF in >> InputStream java >> docs, but is a condition I want to be aware of. >> >> Gregg Wonderly >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 gjhanna at gmail.com Thu Mar 8 13:42:52 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Fri, 9 Mar 2007 09:42:52 +1300 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? Message-ID: I've just struck an issue using rxtx in a multi-threaded environment: If I have 3 threads trying to open *the same* comm-port I get a deadlock in CommPortIdentifier.open If I have just 2, it works fine - I get a PortInUseException which is nice and I can handle it. The 3 thread->deadlock thing is causing me issues. (Sample code below). This is from the java thread-dump Found one Java-level deadlock: ============================= "Thread-2": waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object ), which is held by "Thread-1" "Thread-1": waiting to lock monitor 0x0003e9cc (object 0x2450e108, a gnu.io.CommPortIdentifier), which is held by "Thread-2" Java stack information for the threads listed above: =================================================== "Thread-2": at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:329) - waiting to lock <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) "Thread-1": at java.lang.Object.wait(Native Method) - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) - locked <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) (Apart from this, rxtx is working fantastically for us). I'm thinking I'll have to implement some sort of locking mechanism that *doesn't* use java synchronization to prevent this situation. (Which doesn't sound like a good idea to me). Any ideas? Thanks, Greg Hanna ============= RXTXLockTest.java ======================================== import gnu.io.CommPort; import gnu.io.CommPortIdentifier; /** * @author Greg Hanna * Minimal code to create a deadlock with rxtx in multithreaded open */ public class RXTXLockTest { public static void main(String[] args) { try { CommPortIdentifier cpiCom1 = CommPortIdentifier.getPortIdentifier ("COM14"); OpenThread t1 = new OpenThread (" one ", cpiCom1); OpenThread t2 = new OpenThread (" two ", cpiCom1); OpenThread t3 = new OpenThread (" 003 ", cpiCom1); t1.start(); t2.start(); t3.start(); // comment this out and it runs with (expected) PortInUseException } catch (Exception e) { e.printStackTrace(); } } } class OpenThread extends Thread { String name; CommPortIdentifier cpi; CommPort cp; public OpenThread (String name, CommPortIdentifier cpi) { this.name = name; this.cpi = cpi; System.out.println (System.currentTimeMillis() + name + " thread created"); } public void run () { try { System.out.println (System.currentTimeMillis() + name + " opening"); cp = cpi.open(name, 2000); System.out.println (System.currentTimeMillis() + name + " opened - sleeping"); sleep (2000); // do the serial comms with the device. System.out.println (System.currentTimeMillis() + name + " slept - closing"); cp.close(); System.out.println (System.currentTimeMillis() + name + " closed - exiting"); } catch (Exception e) { System.out.println ("Error in thread: " + name ); e.printStackTrace(); } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070308/d9a163c5/attachment.html From eu259473 at tele2.it Fri Mar 9 02:46:20 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 09 Mar 2007 10:46:20 +0100 Subject: [Rxtx] rxtx: tru64 unix make fails Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070309/3b654523/attachment.html From lyon at docjava.com Fri Mar 9 03:58:32 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 Mar 2007 05:58:32 -0500 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi All, The deadlock issue is one that I have been thinking about for some time now. It seems to me that we need a resource manager that enables assignment to a known process. The one thing that seems important about serial ports is that two applications should not use the same serial port at the same time. When this happens, it throws an exception. OK. The exception is a response to a lock condition that arises from an unavailable resource. An abstract implementation (not born of native methods) might assign a serial port to an application, until the application releases it (or is forced to release it by some kill mechanism). Some resources (like a registry) can be reused. But others, like the serial port, cannot. In the case of the serial port, we would like, I think, to have the flyweight design pattern without sharing and with object assignment tracking. A means of breaking deadlock (like a leasing mechanism) seems very useful, to me. My guess is that we can serialize the state of the Parametric Singleton Pattern (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) into the Preferences of the System. Preferences.systemRoot() might help with that. When a resource is checked out, the lease time and owner are listed. A thread that does this can be killed, but applications outside of Java are problematic. There is a compelling problem here. It is not just serial ports. Sound cards, cameras, microphones, files, tape drives, etc. All are consumed resources that are assigned to an application (or user) and deprive other applications, or users, from use. What, if anything, should we do? At present we throw PortInUseExceptions. Is that it? Can we do better? OK, the port is in use. Now what? Do I have to be root to go remove lock files and kill applications? Is there a better way? Thanks! - Doug >I've just struck an issue using rxtx in a multi-threaded environment: > >If I have 3 threads trying to open *the same* >comm-port I get a deadlock in >CommPortIdentifier.open >If I have just 2, it works fine - I get a >PortInUseException which is nice and I can >handle it. > >The 3 thread->deadlock thing is causing me issues. >(Sample code below). > >This is from the java thread-dump > >Found one Java-level deadlock: >============================= >"Thread-2": > waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), > which is held by "Thread-1" >"Thread-1": > waiting to lock monitor 0x0003e9cc (object >0x2450e108, a gnu.io.CommPortIdentifier ), > which is held by "Thread-2" > >Java stack information for the threads listed above: >=================================================== >"Thread-2": > at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) > - waiting to lock <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) >"Thread-1": > at java.lang.Object.wait(Native Method) > - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) > - locked <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) > > >(Apart from this, rxtx is working fantastically for us). > >I'm thinking I'll have to implement some sort of >locking mechanism that *doesn't* use java >synchronization to prevent this situation. >(Which doesn't sound like a good idea to me). > >Any ideas? > >Thanks, > >Greg Hanna > >============= RXTXLockTest.java ======================================== > >import gnu.io.CommPort; >import gnu.io.CommPortIdentifier; > >/** > * @author Greg Hanna > * Minimal code to create a deadlock with rxtx in multithreaded open > */ >public class RXTXLockTest { > ? > ?public static void main(String[] args) { > ?try { > ?CommPortIdentifier cpiCom1 = >CommPortIdentifier.getPortIdentifier ("COM14"); > ?OpenThread t1 = new OpenThread (" one ", cpiCom1); > ?OpenThread t2 = new OpenThread (" two ", cpiCom1); > ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); > ?t1.start(); > ?t2.start(); > ?t3.start(); // comment this out >and it runs with (expected) PortInUseException > ?} catch (Exception e) { > ?e.printStackTrace(); > ?} > ?} >} > >class OpenThread extends Thread { > ?String name; > ?CommPortIdentifier cpi; > ?CommPort cp; > ?public OpenThread (String name, CommPortIdentifier cpi) { > ? this.name = name; > ?this.cpi = cpi; > ?System.out.println >(System.currentTimeMillis() + name + " thread >created"); > ?} > ?public void run () { > ?try { > ?System.out.println >(System.currentTimeMillis() + name + " opening"); > ?cp = cpi.open(name, 2000); > ?System.out.println >(System.currentTimeMillis() + name + " opened - >sleeping"); > ?sleep (2000); // do the serial comms with the device. > ?System.out.println >(System.currentTimeMillis() + name + " slept - >closing"); > ?cp.close(); > ?System.out.println >(System.currentTimeMillis() + name + " closed - >exiting"); > ?} catch (Exception e) { > System.out.println ("Error in thread: " + name ); > ?e.printStackTrace(); > ?} > ?} >} > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Mar 9 06:37:45 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 Mar 2007 06:37:45 -0700 (MST) Subject: [Rxtx] rxtx: tru64 unix make fails In-Reply-To: References: Message-ID: On Fri, 9 Mar 2007, "Giuseppe Marchese" wrote: > Sorry for delay. > ? > This is log for ./configure and make > error. > ? > thanks for attention > ? > Make: '%.java,$(TOP)/$(CLASSDEST)/%.class,$(wildcard $(SPATH)/*.java)': extra chars.? > Stop. > Hi Giuseppe You need to use GNU make with the Makefile. I suspect the tru64 make is not happy with those rules. > configure: exit 0 Looks like configure is fairly happy. From tjarvi at qbang.org Sat Mar 10 07:43:51 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 07:43:51 -0700 (MST) Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi Doug I have very little time to look into this further but what we could do is open up an rxtx 3 devel branch in which a proof of concept could be worked on. It could be the proof of concept for a JSR others including Sun could look at/work on or parts of it could be recycled in a JSR. I'm working very hard on rxtx right now but it does not show. I'm looking at win64, mac intel/ppc, usb bluetooth and usb serial dongles. Some are going to be more tested than others but they are all on the plate. I'll be pushing all the fixes upstream when they are done. So I'm very busy in 2.1 but we could open a new branch. On Fri, 9 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > The deadlock issue is one that I have been thinking about > for some time now. > It seems to me that we need a resource manager that enables assignment > to a known process. > > The one thing that seems important about serial > ports is that two applications should not use the > same serial port at the same time. When this > happens, it throws an exception. > OK. > > The exception is a response to a lock condition that > arises from an unavailable resource. > > An abstract implementation (not born of native methods) might > assign a serial port to an application, until the > application releases it (or is forced to release > it by some kill mechanism). > > Some resources (like a registry) can be reused. > But others, like the serial port, > cannot. > > In the case of the serial port, we would like, I think, to > have the flyweight design pattern > without sharing and with object assignment tracking. > A means of breaking deadlock (like a leasing > mechanism) seems very useful, to me. > > My guess is that we can serialize the state of the Parametric Singleton Pattern > (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) > into the Preferences of the System. Preferences.systemRoot() might help > with that. When a resource is checked out, the lease time and owner are > listed. A thread that does this can be killed, but applications outside of Java > are problematic. > > There is a compelling problem here. It is not just serial ports. > Sound cards, cameras, microphones, files, tape drives, etc. All are consumed > resources that are assigned to an application (or > user) and deprive other applications, > or users, from use. > > What, if anything, should we do? At present we throw PortInUseExceptions. > Is that it? > Can we do better? > OK, the port is in use. Now what? > Do I have to be root to go remove lock files and kill applications? > Is there a better way? > > Thanks! > - Doug > >> I've just struck an issue using rxtx in a multi-threaded environment: >> >> If I have 3 threads trying to open *the same* >> comm-port I get a deadlock in >> CommPortIdentifier.open >> If I have just 2, it works fine - I get a >> PortInUseException which is nice and I can >> handle it. >> >> The 3 thread->deadlock thing is causing me issues. >> (Sample code below). >> >> This is from the java thread-dump >> >> Found one Java-level deadlock: >> ============================= >> "Thread-2": >> waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), >> which is held by "Thread-1" >> "Thread-1": >> waiting to lock monitor 0x0003e9cc (object >> 0x2450e108, a gnu.io.CommPortIdentifier ), >> which is held by "Thread-2" >> >> Java stack information for the threads listed above: >> =================================================== >> "Thread-2": >> at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) >> - waiting to lock <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> "Thread-1": >> at java.lang.Object.wait(Native Method) >> - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) >> - locked <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> >> >> (Apart from this, rxtx is working fantastically for us). >> >> I'm thinking I'll have to implement some sort of >> locking mechanism that *doesn't* use java >> synchronization to prevent this situation. >> (Which doesn't sound like a good idea to me). >> >> Any ideas? >> >> Thanks, >> >> Greg Hanna >> >> ============= RXTXLockTest.java ======================================== >> >> import gnu.io.CommPort; >> import gnu.io.CommPortIdentifier; >> >> /** >> * @author Greg Hanna >> * Minimal code to create a deadlock with rxtx in multithreaded open >> */ >> public class RXTXLockTest { >> ? >> ?public static void main(String[] args) { >> ?try { >> ?CommPortIdentifier cpiCom1 = >> CommPortIdentifier.getPortIdentifier ("COM14"); >> ?OpenThread t1 = new OpenThread (" one ", cpiCom1); >> ?OpenThread t2 = new OpenThread (" two ", cpiCom1); >> ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); >> ?t1.start(); >> ?t2.start(); >> ?t3.start(); // comment this out >> and it runs with (expected) PortInUseException >> ?} catch (Exception e) { >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> class OpenThread extends Thread { >> ?String name; >> ?CommPortIdentifier cpi; >> ?CommPort cp; >> ?public OpenThread (String name, CommPortIdentifier cpi) { >> ? this.name = name; >> ?this.cpi = cpi; >> ?System.out.println >> (System.currentTimeMillis() + name + " thread >> created"); >> ?} >> ?public void run () { >> ?try { >> ?System.out.println >> (System.currentTimeMillis() + name + " opening"); >> ?cp = cpi.open(name, 2000); >> ?System.out.println >> (System.currentTimeMillis() + name + " opened - >> sleeping"); >> ?sleep (2000); // do the serial comms with the device. >> ?System.out.println >> (System.currentTimeMillis() + name + " slept - >> closing"); >> ?cp.close(); >> ?System.out.println >> (System.currentTimeMillis() + name + " closed - >> exiting"); >> ?} catch (Exception e) { >> System.out.println ("Error in thread: " + name ); >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 mm at UDel.Edu Sat Mar 10 14:48:32 2007 From: mm at UDel.Edu (Mike Markowski) Date: Sat, 10 Mar 2007 16:48:32 -0500 Subject: [Rxtx] rxtx and Sun's comm api Message-ID: <45F327B0.2060004@udel.edu> Hi all, I joined the list a few days ago and apologize for what is likely a frequently asked question, though I haven't yet found it anywhere. I learned about rxtx.org through the readme on Sun's version 2 of their comms api. They give recommendations in that readme regarding how a better comms api should be written. Is this the aim of rxtx.org? I wrote an app on my linux box using the Sun comms api (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the fact that only linux and Solaris are supported. So I'm glad to find rxtx.org and am just reading up on how make the conversion so Windows users will be able to run the program as well. At the same time I'm just curious if rxtx.org and Sun are both heading in the same direction. Thanks for any background or historical info. Feel free to point me to any www pages if my googling has just completely missed the target! Thanks again, Mike From tjarvi at qbang.org Sat Mar 10 15:35:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 15:35:25 -0700 (MST) Subject: [Rxtx] rxtx and Sun's comm api In-Reply-To: <45F327B0.2060004@udel.edu> References: <45F327B0.2060004@udel.edu> Message-ID: On Sat, 10 Mar 2007, Mike Markowski wrote: > Hi all, > > I joined the list a few days ago and apologize for what is likely a > frequently asked question, though I haven't yet found it anywhere. I > learned about rxtx.org through the readme on Sun's version 2 of their > comms api. They give recommendations in that readme regarding how a > better comms api should be written. Is this the aim of rxtx.org? > > I wrote an app on my linux box using the Sun comms api > (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the > fact that only linux and Solaris are supported. So I'm glad to find > rxtx.org and am just reading up on how make the conversion so Windows > users will be able to run the program as well. At the same time I'm > just curious if rxtx.org and Sun are both heading in the same direction. > > Thanks for any background or historical info. Feel free to point me to > any www pages if my googling has just completely missed the target! > I do not have any news (good or bad) concerning RXTX and Sun working together but perhaps others here do. The main goal of RXTX is to expose POSIX termios interfaces to java users. The future support of javax.comm is questionable. We do not have resources for everything. gnu.io (RXTX 2.1) will be supported going forward and functions the same as CommAPI 2.0. If you have control of the source code you are working with, I would not advise using CommAPI 2.0 javax.comm. We do support CommAPI 2.0 javax.comm for older applications but I do not think that will last much longer for practical reasons. The download interest in CommAPI 2.0 javax.comm support is becomming negligible on this end. There has been discussion of a JSR effort but I do not know of any status change since it was mentioned. One problem with a JSR is that even a light weight process is going to be difficult for RXTX at this time. Maybe that will change in the future but then again it may not. For now, we are just going forward 'as is' in rxtx 2.1 with package gnu.io while trying as a secondary effort to backport the changes to rxtx 2.0 for javax.comm support for users that do not have a choice. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Mar 11 07:19:40 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 11 Mar 2007 08:19:40 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: Hi All, I have been a proponent of a JSR that makes use of RXTX. I have executed the proper agreements with Sun. At this point we are in the: Early Draft Review of Draft Specifications Stage. The best thing to do is to enter the quiet period and create a specification. The question of exactly how we, as a group, want to approach this problem, remains open. Typically, we should have both a specification and a reference implementation. Thus, it would be to our best advantage to have a nice, stable, cross platform RXTX distro that adheres to the groups specification. Now, from a specification standpoint, my personal view on the matter is that we create a series of interfaces, with nice documentation (or at least javadoc). Is this a good idea? Should we have a pure interface specification for the communication API? There are several issues, in my mind, which still weigh on us. Hot-pluggable dongles, long discovery process on pop-up ports, lack of uniformity on device names, lack of uniformity on locking, a precise understanding of how the SerialPortResourceManager works (or even if we should have one). The more questions we answer in our reference implementation, the better our specification will get. RXTX is a good working prototype, but, I don't know if that is what we want to use for a specification. Here is what I have for a CommPortInterface: */ public interface CommPortInterface { /** * @return a string representation of this port. */ String toString(); /** * Gets the name of the communications port. This name should correspond to * something the user can identify, like the label on the hardware. * @return name of the port */ String getName(); /** * @return an input stream that can be used to read data from the * communications port. If the port doesn't support reading data, this * method returns null. *

* The blocking behaviour of this input stream depends on the threshold * and timeout values, as shown below for a read buffer size of n * bytes: * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ThresholdTimeoutBlocking behaviour
StateValueStateValue
disableddisabledblock until data is available
enabledm bytesdisabledblock until min(m, n) bytes are available
disabledenabledt msblock for t ms or until data is available
enabledm bytesenabledt msblock for t ms or until min(m, n) bytes are * available
* @throws java.io.IOException */ InputStream getInputStream() throws IOException; /** * @return an output stream that can be used to send data to the * communications port. If the port doesn't support sending data, this * method returns null. * @throws java.io.IOException */ OutputStream getOutputStream() throws IOException; /** * Closes this communications port. * All PortOwnershipListeners will be? * notified of this change of ownership. Further method calls on this? * object will throw IllegalStateException. Further calls on the? * associated InputStream or OutputStream will throw IOException. *

* Close does not block. Undelivered data is discarded. Blocked read and? * write operations are aborted if the underlying operating systems? * supports an IO abort mechanism. To await the delivery of undelivered? * data call OutputStream.flush() or OutputStream.close() before calling? * Port.close(). */ void close(); /** * Enables receive threshold. * When the specified threshold number of bytes are retrieved, read will * return immediately. * * @param thresh the number of bytes in the input buffer * @throws gnu.io.UnsupportedCommOperationException * if receive threshold is * not supported by the driver * @see #disableReceiveThreshold */ void enableReceiveThreshold(int thresh) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive threshold. * * @see #enableReceiveThreshold */ void disableReceiveThreshold(); /** * @return true if receive threshold is enabled. * * @see #enableReceiveThreshold */ boolean isReceiveThresholdEnabled(); /** * @return the receive threshold value. If receive threshold is diabled * or not supported, this value is meaningless. * * @see #enableReceiveThreshold */ int getReceiveThreshold(); /** * Enables receive timeout. * When the specified number of milliseconds have elapsed, read will * return immediately. * * @param rcvTimeout the number of milliseconds to block for * @throws gnu.io.UnsupportedCommOperationException * if receive timeout is * not supported by the driver * @see #disableReceiveTimeout */ void enableReceiveTimeout(int rcvTimeout) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive timeout. * * @see #enableReceiveTimeout */ void disableReceiveTimeout(); /** * @return true if receive timeout is enabled. * * @see #enableReceiveTimeout */ boolean isReceiveTimeoutEnabled(); /** * @return the receive timeout value. If receive timeout is diabled * or not supported, this value is meaningless. * * @see #enableReceiveTimeout */ int getReceiveTimeout(); /** * Enables receive framing. * The supplied byte value in the input suggests the end of the received * frame, and read returns immediately. Only the low 8 bits of the * supplied value are significant. * * @param framingByte the frame delimiter * @throws gnu.io.UnsupportedCommOperationException * if receive framing is * not supported by the driver * @see #disableReceiveFraming */ void enableReceiveFraming(int framingByte) throws UnsupportedCommOperationException; /** * Disables receive framing. * * @see #enableReceiveFraming */ void disableReceiveFraming(); /** * @return true if receive framing is enabled. * * @see #enableReceiveFraming */ boolean isReceiveFramingEnabled(); /** * @return true if receive framing byte. If receive framing is diabled * or not supported, this value is meaningless. * * @see #enableReceiveFraming */ int getReceiveFramingByte(); /** * Sets the input buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setInputBufferSize(int size); /** * @return the input buffer size. * The driver may choose not to report correct values. */ int getInputBufferSize(); /** * Sets the output buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setOutputBufferSize(int size); /** * @return the output buffer size. * The driver may choose not to report correct values. */ int getOutputBufferSize(); } What do you think of that? Note the wishy washy nature of the spec: The driver may choose to ignore this method. Is that good enough for us? Thanks! - Doug From ra85551 at gmail.com Sun Mar 11 08:44:45 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Sun, 11 Mar 2007 17:44:45 +0300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hello, world! I am writing application that communicates with modem via AT commands. My OS is Linux Kubuntu Feisty Herd, to ensure that my application will run properly under Windows XP I installed VMWare server. When I tried to send AT command and evaluate modem answer under WinXP @ VMWare server, I actually didn't receive anything. I think that VM settings are right, because I do can communicate with modem by using standard HyperTerminall as well as I can do on native Windows. So, why RXTX doesn't work under VM, but works under Linux and pure Windows XP (i tested it there) well? The send/receive method code follows. private String sendATCommand(String command, final String waitFor, final boolean isRegex, boolean isAddCRLF, long timeout) throws BeaconConnectException { final long POLL_PERIOD = 100; final int BUFFER_SIZE = 512; final byte[] buffer = new byte[BUFFER_SIZE]; final InputStream serialInput; final OutputStream serialOutput; try { serialInput = serialPort.getInputStream(); if (command != null) { serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } } catch (IOException e) { throw new MyException("serial I/O error"); } TimerTask task = new TimerTask() { int offset = 0; int bytesRead; public synchronized void run() { try { if (serialInput.available() > 0) { bytesRead = serialInput.read(buffer, offset, BUFFER_SIZE - offset); } else { return; } } catch (IOException e) { // do nothing - maybe next time we'll read something } offset += bytesRead; if (waitFor != null) { String temporary = new String(buffer, 0, offset).trim(); if (isRegex && temporary.matches(waitFor) || temporary.contains(waitFor)) { cancel(); notify(); } } } }; Timer timer = new Timer(); timer.schedule(task, POLL_PERIOD, POLL_PERIOD); synchronized (task) { try { task.wait(timeout); task.cancel(); } catch (InterruptedException e) { } } //Cut off leading and trailing CRs, LFs and zeroes String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); System.out.println(response); return response; } -- Pavel Parkhomenko From tjarvi at qbang.org Sun Mar 11 11:48:22 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:48:22 -0600 (MDT) Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: On Sun, 11 Mar 2007, Pavel Parkhomenko wrote: > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. > > private String sendATCommand(String command, final String waitFor, > final boolean isRegex, boolean isAddCRLF, long timeout) > throws BeaconConnectException > { > final long POLL_PERIOD = 100; > final int BUFFER_SIZE = 512; > final byte[] buffer = new byte[BUFFER_SIZE]; > final InputStream serialInput; > final OutputStream serialOutput; > try > { > serialInput = serialPort.getInputStream(); > if (command != null) > { > serialOutput = serialPort.getOutputStream(); > if (isAddCRLF) > { > command += "\r\n"; > } > System.out.println(command); > serialOutput.write(command.getBytes()); > } > } > catch (IOException e) > { > throw new MyException("serial I/O error"); > } > > TimerTask task = new TimerTask() > { > int offset = 0; > int bytesRead; > public synchronized void run() > { > try > { > if (serialInput.available() > 0) > { > bytesRead = serialInput.read(buffer, offset, > BUFFER_SIZE - offset); > } > else > { > return; > } > } > catch (IOException e) > { > // do nothing - maybe next time we'll read something > } > offset += bytesRead; > if (waitFor != null) > { > String temporary = new String(buffer, 0, offset).trim(); > if (isRegex && temporary.matches(waitFor) || > temporary.contains(waitFor)) > { > cancel(); > notify(); > } > } > } > }; > > Timer timer = new Timer(); > timer.schedule(task, POLL_PERIOD, POLL_PERIOD); > synchronized (task) { > try > { > task.wait(timeout); > task.cancel(); > } > catch (InterruptedException e) > { > } > } > //Cut off leading and trailing CRs, LFs and zeroes > String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); > System.out.println(response); > return response; > } > > > Hi Pavel VMWare should not be a problem. I've used it in the past - though not with a modem. Make sure nothing else is using the modem. Then look in the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an example that should work. Note that modems could care less what OS is on top. If you are trying to match new lines to the OS and sending it to the mode for AT commands, thats probably a mistake. Also it would not hurt to print out the individual bytes that you are sending to make sure they did not get mangled along the path. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 11:55:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:55:48 -0600 (MDT) Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: On Sun, 11 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > I have been a proponent of a JSR that makes > use of RXTX. I have executed the proper agreements with Sun. > > At this point we are in the: > Early Draft Review of Draft Specifications Stage. > > The best thing to do is to enter the quiet period and create > a specification. The question of exactly how we, as a group, > want to approach this problem, remains open. > > Typically, we should have both a specification and a reference > implementation. Thus, it would be to our best advantage to have > a nice, stable, cross platform RXTX distro that adheres to the > groups specification. > > Now, from a specification standpoint, my personal view on the matter is > that we create a series of interfaces, with nice documentation (or at least > javadoc). > > Is this a good idea? Should we have a pure interface specification for > the communication API? > > There are several issues, in my mind, which still weigh on us. > Hot-pluggable dongles, long discovery process on pop-up ports, > lack of uniformity on device names, lack of uniformity on locking, > a precise understanding of how the SerialPortResourceManager > works (or even if we should have one). > > The more questions we answer in our reference implementation, the > better our specification will get. RXTX is a good working prototype, > but, I don't know if that is what we want to use for a specification. > > Here is what I have for a CommPortInterface: > */ > public interface CommPortInterface { Hi Doug, I can start going through the method interfaces later this week and giving feedback. I would suggest that the JSR should not be too generic in nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel drivers that intend to look like EIA232 ports at the kernel driver level. some ideas: EIA232PortInterface TermiosInterface SerialPortInterface Something that differentiates this from thing like USB, I2C, ... which should not have to deal with legacy serial claiming to be the comm api. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 12:52:19 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 12:52:19 -0600 (MDT) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: No news is good news with these posts. I'll start the process of pinging legal a week from Monday on my end if nobody has objections to the proposal. I just want to make sure everyone has time to raise objections. Obviously, anyone can fork from a previous version if they don't like the new license. I suspect we can avoid that though. On Sun, 4 Mar 2007, Trent Jarvi wrote: > > For those that are wondering what is going on here, this > next bit is the meat of the changes. We agreed a long time > ago to put this disclaimer in. We did a so so job. It was > in rxtx 2.0, not well written, ... So some groups using > rxtx that would like to ship rxtx so users don't need to > download, install, go to the mail-list to find why it failed, > ... Then their legal teams tell them section 5 paragraph 2 > is a show stopper. > > That was never the intent. > > > Now going through what remains... > >> and might need a (TM) suffix to make Sun happy. > > Added disclaimer at the ended 'all trademarks belong...' > >> * Line #15ff - static vs. dynamic linking - you did >> not transcribe the text from the "controlled >> interface exception" when writing this text - and >> this was good so, because these terms originally >> refer to the GPL rather than the LGPL. I think though, >> that these 4 lines are the most important ones and >> should thus be really really clear. I hope that I >> meet your original intent with the following >> suggestions: >> 1.) Instead of "A program.." it would be better to >> say "An exectuable.." in order to be closer to >> the LGPL text. > > OK. As you can see I was trying to adjust GNU text there > for the LGPL. > >> 2.) It would be better to say .. "by being dynamically >> linked with it" to clearly indicate that dynamic >> linking is meant. The matter of compilation is >> already covered by the LGPL so mentioning it again >> just leads to confusion. > > used dynamically linked terminology. > >> 3.) It would be better to say .. "is considered a >> work that uses the library in contrast to section >> 5 of the LGPL, so the terms of the LGPL do not >> apply to the resulting executable". > > I tried to address this more upfront with an intent statement. > Let me know if you have problems with it. I also tried to > make it a little more clear what was derived from the GNU > solution by moving the link location closer to GNU's suggestion. > >> >> Note that LGPL section 5 says: ..."is called a >> "work that uses the Library". Such a work, in isolation, >> is not a derivative work of the Library, and therefore >> falls outside the scope of this License." >> The next paragraph of the LGPL is exactly the problematic >> one that I hope is clarified by the exception terms you >> give. >> > > Thats the intent. Here is the combined fixes. Note that only the > material in /*-- --*/ is being touched. The new GPL license is > there but unmodified. > > > ------------------------ begin proposed new license ------------------- > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Lesser General Public > | License as published by the Free Software Foundation; either > | version 2.1 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Lesser General Public License for more details. > | > | An executable that contains no derivative of any portion of RXTX, but > | is designed to work with RXTX by being dynamically linked with it, > | is considered a "work that uses the Library" subject to the terms and > | conditions of the GNU Lesser General Public License. > | > | The following has been added to the RXTX License to remove > | any confusion about linking to RXTX. We want to allow in part what > | section 5, paragraph 2 of the LGPL does not permit in the special > | case of linking over a controlled interface. The intent is to add a > | Java Specification Request or standards body defined interface in the > | future as another exception but one is not currently available. > | > | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface > | > | As a special exception, the copyright holders of RXTX give you > | permission to link RXTX with independent modules that communicate with > | RXTX solely through the Sun Microsytems CommAPI interface version 2, > | regardless of the license terms of these independent modules, and to copy > | and distribute the resulting combined work under terms of your choice, > | provided that every copy of the combined work is accompanied by a complete > | copy of the source code of RXTX (the version of RXTX used to produce the > | combined work), being distributed under the terms of the GNU Lesser General > | Public License plus this exception. An independent module is a > | module which is not derived from or based on RXTX. > | > | Note that people who make modified versions of RXTX are not obligated > | to grant this special exception for their modified versions; it is > | their choice whether to do so. The GNU Lesser General Public License > | gives permission to release a modified version without this exception; this > | exception also makes it possible to release a modified version which > | carries forward this exception. > | > | You should have received a copy of the GNU Lesser General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > | All trademarks belong to their respective owners. > --------------------------------------------------------------------------*/ > > The original GNU Lesser General Public License Follows. > > > GNU LESSER GENERAL PUBLIC LICENSE > Version 2.1, February 1999 > > Copyright (C) 1991, 1999 Free Software Foundation, Inc. > 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > Everyone is permitted to copy and distribute verbatim copies > of this license document, but changing it is not allowed. > > [This is the first released version of the Lesser GPL. It also counts > as the successor of the GNU Library Public License, version 2, hence > the version number 2.1.] > > Preamble > > The licenses for most software are designed to take away your > freedom to share and change it. By contrast, the GNU General Public > Licenses are intended to guarantee your freedom to share and change > free software--to make sure the software is free for all its users. > > This license, the Lesser General Public License, applies to some > specially designated software packages--typically libraries--of the > Free Software Foundation and other authors who decide to use it. You > can use it too, but we suggest you first think carefully about whether > this license or the ordinary General Public License is the better > strategy to use in any particular case, based on the explanations below. > > When we speak of free software, we are referring to freedom of use, > not price. Our General Public Licenses are designed to make sure that > you have the freedom to distribute copies of free software (and charge > for this service if you wish); that you receive source code or can get > it if you want it; that you can change the software and use pieces of > it in new free programs; and that you are informed that you can do > these things. > > To protect your rights, we need to make restrictions that forbid > distributors to deny you these rights or to ask you to surrender these > rights. These restrictions translate to certain responsibilities for > you if you distribute copies of the library or if you modify it. > > For example, if you distribute copies of the library, whether gratis > or for a fee, you must give the recipients all the rights that we gave > you. You must make sure that they, too, receive or can get the source > code. If you link other code with the library, you must provide > complete object files to the recipients, so that they can relink them > with the library after making changes to the library and recompiling > it. And you must show them these terms so they know their rights. > > We protect your rights with a two-step method: (1) we copyright the > library, and (2) we offer you this license, which gives you legal > permission to copy, distribute and/or modify the library. > > To protect each distributor, we want to make it very clear that > there is no warranty for the free library. Also, if the library is > modified by someone else and passed on, the recipients should know > that what they have is not the original version, so that the original > author's reputation will not be affected by problems that might be > introduced by others. > > Finally, software patents pose a constant threat to the existence of > any free program. We wish to make sure that a company cannot > effectively restrict the users of a free program by obtaining a > restrictive license from a patent holder. Therefore, we insist that > any patent license obtained for a version of the library must be > consistent with the full freedom of use specified in this license. > > Most GNU software, including some libraries, is covered by the > ordinary GNU General Public License. This license, the GNU Lesser > General Public License, applies to certain designated libraries, and > is quite different from the ordinary General Public License. We use > this license for certain libraries in order to permit linking those > libraries into non-free programs. > > When a program is linked with a library, whether statically or using > a shared library, the combination of the two is legally speaking a > combined work, a derivative of the original library. The ordinary > General Public License therefore permits such linking only if the > entire combination fits its criteria of freedom. The Lesser General > Public License permits more lax criteria for linking other code with > the library. > > We call this license the "Lesser" General Public License because it > does Less to protect the user's freedom than the ordinary General > Public License. It also provides other free software developers Less > of an advantage over competing non-free programs. These disadvantages > are the reason we use the ordinary General Public License for many > libraries. However, the Lesser license provides advantages in certain > special circumstances. > > For example, on rare occasions, there may be a special need to > encourage the widest possible use of a certain library, so that it becomes > a de-facto standard. To achieve this, non-free programs must be > allowed to use the library. A more frequent case is that a free > library does the same job as widely used non-free libraries. In this > case, there is little to gain by limiting the free library to free > software only, so we use the Lesser General Public License. > > In other cases, permission to use a particular library in non-free > programs enables a greater number of people to use a large body of > free software. For example, permission to use the GNU C Library in > non-free programs enables many more people to use the whole GNU > operating system, as well as its variant, the GNU/Linux operating > system. > > Although the Lesser General Public License is Less protective of the > users' freedom, it does ensure that the user of a program that is > linked with the Library has the freedom and the wherewithal to run > that program using a modified version of the Library. > > The precise terms and conditions for copying, distribution and > modification follow. Pay close attention to the difference between a > "work based on the library" and a "work that uses the library". The > former contains code derived from the library, whereas the latter must > be combined with the library in order to run. > > GNU LESSER GENERAL PUBLIC LICENSE > TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION > > 0. This License Agreement applies to any software library or other > program which contains a notice placed by the copyright holder or > other authorized party saying it may be distributed under the terms of > this Lesser General Public License (also called "this License"). > Each licensee is addressed as "you". > > A "library" means a collection of software functions and/or data > prepared so as to be conveniently linked with application programs > (which use some of those functions and data) to form executables. > > The "Library", below, refers to any such software library or work > which has been distributed under these terms. A "work based on the > Library" means either the Library or any derivative work under > copyright law: that is to say, a work containing the Library or a > portion of it, either verbatim or with modifications and/or translated > straightforwardly into another language. (Hereinafter, translation is > included without limitation in the term "modification".) > > "Source code" for a work means the preferred form of the work for > making modifications to it. For a library, complete source code means > all the source code for all modules it contains, plus any associated > interface definition files, plus the scripts used to control compilation > and installation of the library. > > Activities other than copying, distribution and modification are not > covered by this License; they are outside its scope. The act of > running a program using the Library is not restricted, and output from > such a program is covered only if its contents constitute a work based > on the Library (independent of the use of the Library in a tool for > writing it). Whether that is true depends on what the Library does > and what the program that uses the Library does. > > 1. You may copy and distribute verbatim copies of the Library's > complete source code as you receive it, in any medium, provided that > you conspicuously and appropriately publish on each copy an > appropriate copyright notice and disclaimer of warranty; keep intact > all the notices that refer to this License and to the absence of any > warranty; and distribute a copy of this License along with the > Library. > > You may charge a fee for the physical act of transferring a copy, > and you may at your option offer warranty protection in exchange for a > fee. > > 2. You may modify your copy or copies of the Library or any portion > of it, thus forming a work based on the Library, and copy and > distribute such modifications or work under the terms of Section 1 > above, provided that you also meet all of these conditions: > > a) The modified work must itself be a software library. > > b) You must cause the files modified to carry prominent notices > stating that you changed the files and the date of any change. > > c) You must cause the whole of the work to be licensed at no > charge to all third parties under the terms of this License. > > d) If a facility in the modified Library refers to a function or a > table of data to be supplied by an application program that uses > the facility, other than as an argument passed when the facility > is invoked, then you must make a good faith effort to ensure that, > in the event an application does not supply such function or > table, the facility still operates, and performs whatever part of > its purpose remains meaningful. > > (For example, a function in a library to compute square roots has > a purpose that is entirely well-defined independent of the > application. Therefore, Subsection 2d requires that any > application-supplied function or table used by this function must > be optional: if the application does not supply it, the square > root function must still compute square roots.) > > These requirements apply to the modified work as a whole. If > identifiable sections of that work are not derived from the Library, > and can be reasonably considered independent and separate works in > themselves, then this License, and its terms, do not apply to those > sections when you distribute them as separate works. But when you > distribute the same sections as part of a whole which is a work based > on the Library, the distribution of the whole must be on the terms of > this License, whose permissions for other licensees extend to the > entire whole, and thus to each and every part regardless of who wrote > it. > > Thus, it is not the intent of this section to claim rights or contest > your rights to work written entirely by you; rather, the intent is to > exercise the right to control the distribution of derivative or > collective works based on the Library. > > In addition, mere aggregation of another work not based on the Library > with the Library (or with a work based on the Library) on a volume of > a storage or distribution medium does not bring the other work under > the scope of this License. > > 3. You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. To do > this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version 2, > instead of to this License. (If a newer version than version 2 of the > ordinary GNU General Public License has appeared, then you can specify > that version instead if you wish.) Do not make any other change in > these notices. > > Once this change is made in a given copy, it is irreversible for > that copy, so the ordinary GNU General Public License applies to all > subsequent copies and derivative works made from that copy. > > This option is useful when you wish to copy part of the code of > the Library into a program that is not a library. > > 4. You may copy and distribute the Library (or a portion or > derivative of it, under Section 2) in object code or executable form > under the terms of Sections 1 and 2 above provided that you accompany > it with the complete corresponding machine-readable source code, which > must be distributed under the terms of Sections 1 and 2 above on a > medium customarily used for software interchange. > > If distribution of object code is made by offering access to copy > from a designated place, then offering equivalent access to copy the > source code from the same place satisfies the requirement to > distribute the source code, even though third parties are not > compelled to copy the source along with the object code. > > 5. A program that contains no derivative of any portion of the > Library, but is designed to work with the Library by being compiled or > linked with it, is called a "work that uses the Library". Such a > work, in isolation, is not a derivative work of the Library, and > therefore falls outside the scope of this License. > > However, linking a "work that uses the Library" with the Library > creates an executable that is a derivative of the Library (because it > contains portions of the Library), rather than a "work that uses the > library". The executable is therefore covered by this License. > Section 6 states terms for distribution of such executables. > > When a "work that uses the Library" uses material from a header file > that is part of the Library, the object code for the work may be a > derivative work of the Library even though the source code is not. > Whether this is true is especially significant if the work can be > linked without the Library, or if the work is itself a library. The > threshold for this to be true is not precisely defined by law. > > If such an object file uses only numerical parameters, data > structure layouts and accessors, and small macros and small inline > functions (ten lines or less in length), then the use of the object > file is unrestricted, regardless of whether it is legally a derivative > work. (Executables containing this object code plus portions of the > Library will still fall under Section 6.) > > Otherwise, if the work is a derivative of the Library, you may > distribute the object code for the work under the terms of Section 6. > Any executables containing that work also fall under Section 6, > whether or not they are linked directly with the Library itself. > > 6. As an exception to the Sections above, you may also combine or > link a "work that uses the Library" with the Library to produce a > work containing portions of the Library, and distribute that work > under terms of your choice, provided that the terms permit > modification of the work for the customer's own use and reverse > engineering for debugging such modifications. > > You must give prominent notice with each copy of the work that the > Library is used in it and that the Library and its use are covered by > this License. You must supply a copy of this License. If the work > during execution displays copyright notices, you must include the > copyright notice for the Library among them, as well as a reference > directing the user to the copy of this License. Also, you must do one > of these things: > > a) Accompany the work with the complete corresponding > machine-readable source code for the Library including whatever > changes were used in the work (which must be distributed under > Sections 1 and 2 above); and, if the work is an executable linked > with the Library, with the complete machine-readable "work that > uses the Library", as object code and/or source code, so that the > user can modify the Library and then relink to produce a modified > executable containing the modified Library. (It is understood > that the user who changes the contents of definitions files in the > Library will not necessarily be able to recompile the application > to use the modified definitions.) > > b) Use a suitable shared library mechanism for linking with the > Library. A suitable mechanism is one that (1) uses at run time a > copy of the library already present on the user's computer system, > rather than copying library functions into the executable, and (2) > will operate properly with a modified version of the library, if > the user installs one, as long as the modified version is > interface-compatible with the version that the work was made with. > > c) Accompany the work with a written offer, valid for at > least three years, to give the same user the materials > specified in Subsection 6a, above, for a charge no more > than the cost of performing this distribution. > > d) If distribution of the work is made by offering access to copy > from a designated place, offer equivalent access to copy the above > specified materials from the same place. > > e) Verify that the user has already received a copy of these > materials or that you have already sent this user a copy. > > For an executable, the required form of the "work that uses the > Library" must include any data and utility programs needed for > reproducing the executable from it. However, as a special exception, > the materials to be distributed need not include anything that is > normally distributed (in either source or binary form) with the major > components (compiler, kernel, and so on) of the operating system on > which the executable runs, unless that component itself accompanies > the executable. > > It may happen that this requirement contradicts the license > restrictions of other proprietary libraries that do not normally > accompany the operating system. Such a contradiction means you cannot > use both them and the Library together in an executable that you > distribute. > > 7. You may place library facilities that are a work based on the > Library side-by-side in a single library together with other library > facilities not covered by this License, and distribute such a combined > library, provided that the separate distribution of the work based on > the Library and of the other library facilities is otherwise > permitted, and provided that you do these two things: > > a) Accompany the combined library with a copy of the same work > based on the Library, uncombined with any other library > facilities. This must be distributed under the terms of the > Sections above. > > b) Give prominent notice with the combined library of the fact > that part of it is a work based on the Library, and explaining > where to find the accompanying uncombined form of the same work. > > 8. You may not copy, modify, sublicense, link with, or distribute > the Library except as expressly provided under this License. Any > attempt otherwise to copy, modify, sublicense, link with, or > distribute the Library is void, and will automatically terminate your > rights under this License. However, parties who have received copies, > or rights, from you under this License will not have their licenses > terminated so long as such parties remain in full compliance. > > 9. You are not required to accept this License, since you have not > signed it. However, nothing else grants you permission to modify or > distribute the Library or its derivative works. These actions are > prohibited by law if you do not accept this License. Therefore, by > modifying or distributing the Library (or any work based on the > Library), you indicate your acceptance of this License to do so, and > all its terms and conditions for copying, distributing or modifying > the Library or works based on it. > > 10. Each time you redistribute the Library (or any work based on the > Library), the recipient automatically receives a license from the > original licensor to copy, distribute, link with or modify the Library > subject to these terms and conditions. You may not impose any further > restrictions on the recipients' exercise of the rights granted herein. > You are not responsible for enforcing compliance by third parties with > this License. > > 11. If, as a consequence of a court judgment or allegation of patent > infringement or for any other reason (not limited to patent issues), > conditions are imposed on you (whether by court order, agreement or > otherwise) that contradict the conditions of this License, they do not > excuse you from the conditions of this License. If you cannot > distribute so as to satisfy simultaneously your obligations under this > License and any other pertinent obligations, then as a consequence you > may not distribute the Library at all. For example, if a patent > license would not permit royalty-free redistribution of the Library by > all those who receive copies directly or indirectly through you, then > the only way you could satisfy both it and this License would be to > refrain entirely from distribution of the Library. > > If any portion of this section is held invalid or unenforceable under any > particular circumstance, the balance of the section is intended to apply, > and the section as a whole is intended to apply in other circumstances. > > It is not the purpose of this section to induce you to infringe any > patents or other property right claims or to contest validity of any > such claims; this section has the sole purpose of protecting the > integrity of the free software distribution system which is > implemented by public license practices. Many people have made > generous contributions to the wide range of software distributed > through that system in reliance on consistent application of that > system; it is up to the author/donor to decide if he or she is willing > to distribute software through any other system and a licensee cannot > impose that choice. > > This section is intended to make thoroughly clear what is believed to > be a consequence of the rest of this License. > > 12. If the distribution and/or use of the Library is restricted in > certain countries either by patents or by copyrighted interfaces, the > original copyright holder who places the Library under this License may add > an explicit geographical distribution limitation excluding those countries, > so that distribution is permitted only in or among countries not thus > excluded. In such case, this License incorporates the limitation as if > written in the body of this License. > > 13. The Free Software Foundation may publish revised and/or new > versions of the Lesser General Public License from time to time. > Such new versions will be similar in spirit to the present version, > but may differ in detail to address new problems or concerns. > > Each version is given a distinguishing version number. If the Library > specifies a version number of this License which applies to it and > "any later version", you have the option of following the terms and > conditions either of that version or of any later version published by > the Free Software Foundation. If the Library does not specify a > license version number, you may choose any version ever published by > the Free Software Foundation. > > 14. If you wish to incorporate parts of the Library into other free > programs whose distribution conditions are incompatible with these, > write to the author to ask for permission. For software which is > copyrighted by the Free Software Foundation, write to the Free > Software Foundation; we sometimes make exceptions for this. Our > decision will be guided by the two goals of preserving the free status > of all derivatives of our free software and of promoting the sharing > and reuse of software generally. > > NO WARRANTY > > 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO > WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. > EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR > OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY > KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE > IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE > LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME > THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. > > 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN > WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY > AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU > FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR > CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE > LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING > RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A > FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF > SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH > DAMAGES. > > END OF TERMS AND CONDITIONS > > How to Apply These Terms to Your New Libraries > > If you develop a new library, and you want it to be of the greatest > possible use to the public, we recommend making it free software that > everyone can redistribute and change. You can do so by permitting > redistribution under these terms (or, alternatively, under the terms of the > ordinary General Public License). > > To apply these terms, attach the following notices to the library. It is > safest to attach them to the start of each source file to most effectively > convey the exclusion of warranty; and each file should have at least the > "copyright" line and a pointer to where the full notice is found. > > > Copyright (C) > > This library is free software; you can redistribute it and/or > modify it under the terms of the GNU Lesser General Public > License as published by the Free Software Foundation; either > version 2.1 of the License, or (at your option) any later version. > > This library is distributed in the hope that it will be useful, > but WITHOUT ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > Lesser General Public License for more details. > > You should have received a copy of the GNU Lesser General Public > License along with this library; if not, write to the Free Software > Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > > Also add information on how to contact you by electronic and paper mail. > > You should also get your employer (if you work as a programmer) or your > school, if any, to sign a "copyright disclaimer" for the library, if > necessary. Here is a sample; alter the names: > > Yoyodyne, Inc., hereby disclaims all copyright interest in the > library `Frob' (a library for tweaking knobs) written by James Random Hacker. > > , 1 April 1990 > Ty Coon, President of Vice > > That's all there is to it! > ------------------------ end of proposed license ------------------ > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From gjhanna at gmail.com Sun Mar 11 14:21:17 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Mon, 12 Mar 2007 09:21:17 +1300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hi Pavel, We are using RXTX under VMWare server in production, quite satisfactorily. We're using Red Hat Enterprise Server 4, and ... Whatever the "enterprise" VMWare product is. Regards, Greg H > Subject: [Rxtx] RXTX under VMWare server > To: rxtx at qbang.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. [ ... snip ... ] -- Pavel Parkhomenko -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070311/4cebb6f9/attachment.html From gergg at cox.net Sun Mar 11 23:39:19 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 12 Mar 2007 00:39:19 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: <45F4E787.6050502@cox.net> Trent Jarvi wrote: > I can start going through the method interfaces later this week and giving > feedback. I would suggest that the JSR should not be too generic in > nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel > drivers that intend to look like EIA232 ports at the kernel driver level. > > some ideas: > > EIA232PortInterface > TermiosInterface > SerialPortInterface > > Something that differentiates this from thing like USB, I2C, ... which > should not have to deal with legacy serial claiming to be the comm api. I'm going to throw out a suggestion, which I am mostly serious about. What would happen if we took the appropriate bits of the J2ME connector API, and just used that as the new COMM API so that finally JSE and JME had a common foundation for these kinds of things? Gregg Wonderly From ra85551 at gmail.com Mon Mar 12 09:08:37 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Mon, 12 Mar 2007 18:08:37 +0300 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Should any application use the modem, HyperTerminal won't be able to talk to the modem. But it actually can send and receive AT comands, while my application cannot :-( > Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Thansk for the reference. I examined that example and found that there's no significant differences between my read/write implementation and that one, except that SimpleSnuV1 listens for serialEvent's, but not for sake of data retrieval, just for printing them out - I don't know why ;-) > Note that modems could care less what OS is on top. If you are trying to > match new lines to the OS and sending it to the mode for AT commands, > thats probably a mistake. I do send strings to serial port, not to OS, and do try to get answers back. If it is the mistake, what's the right way? > Also it would not hurt to print out the > individual bytes that you are sending to make sure they did not get > mangled along the path. Yeah, I am printing these bytes before doing write, but it means that I only see what I intend to write. How can I ensure that these bytes have gone out of the box and reached my modem? BTW, I found that my send/receive method is complex enough, so I've rewritten it. Please, see the following code and point any mistakes, because I don't know where can they remain yet. private static final int LARGE_TIMEOUT = 15000; private static final int SMALL_TIMEOUT = 500; ... private String sendATCommand(String command, String waitFor, boolean isRegex, boolean isAddCRLF) throws BeaconConnectException { byte[] buffer = new byte[512]; int offset; String result = ""; try { if (waitFor != null) { serialPort.enableReceiveTimeout(LARGE_TIMEOUT); } else { serialPort.enableReceiveTimeout(SMALL_TIMEOUT); } if (command != null) { OutputStream serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } offset = 0; InputStream serialInput = serialPort.getInputStream(); while (serialInput.available() != -1) { int bytesRead = serialInput.read(buffer, offset, buffer.length - offset); if (bytesRead == 0) { break; } offset += bytesRead; result = new String(buffer, 0, offset).trim(); if (waitFor != null) { System.out.println(result); if (isRegex && result.matches(waitFor) || result.contains(waitFor)) { break; } } } } catch (UnsupportedCommOperationException e) { throw new MyException("unsupported operation"); } catch (IOException e) { throw new MytException("serial I/O error"); } return result; } -- Pavel Parkhomenko From clayno at hotpop.com Thu Mar 15 02:47:34 2007 From: clayno at hotpop.com (Christopher Layno) Date: Thu, 15 Mar 2007 16:47:34 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi, we're using the latest release of rxtx (2.1-7r2) for our system that has two applications using the library. one application sends requests to the modem while the other simply checks the modem status. we deployed our system on a pentium machine with red hat linux 9.0 installed. now the problem arises when these two applications try to access the same modem at the same time. one of them will eventually have to throw the PortInUseException as shown below: 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException gnu.io.PortInUseException: root PID = 743 Program = java root PID = 743 Program = java root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) this was expected. what we didn't expect though was that if we repeat the scenario 5 times, always 5 times, the application would also throw a VM error: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4473CD21 Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so Current Java thread: at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) - locked <0x44cfd4c8> (a gnu.io.CommPortIdentifier) at ************ at ************ - locked <0x4476a468> (a **********) at ************ at ************ at ************ at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java :261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages( TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run( TCPTransport.java:701) at java.lang.Thread.run(Thread.java:534) note: i replaced some sensitive data with asterisks our team has looked everywhere on the internet, including your mail archives, for a solution to this problem but to no avail. i really hope you could help us out on this one. thanks in advance! best regards, chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070315/1936460a/attachment.html From tjarvi at qbang.org Fri Mar 16 04:30:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 04:30:25 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: On Thu, 15 Mar 2007, Christopher Layno wrote: > hi, > > we're using the latest release of rxtx (2.1-7r2) for our system that has two > applications using the library. one application sends requests to the modem > while the other simply checks the modem status. we deployed our system on a > pentium machine with red hat linux 9.0 installed. > > now the problem arises when these two applications try to access the same > modem at the same time. one of them will eventually have to throw the > PortInUseException as shown below: > > 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException > gnu.io.PortInUseException: root PID = 743 Program = java root PID = > 743 Program = java root PID = 743 Program = ??? root PID = 743 Program > = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root > PID = 743 Program = ??? root PID = 743 Program = ??? > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > > this was expected. what we didn't expect though was that if we repeat the > scenario 5 times, always 5 times, the application would also throw a VM > error: > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x4473CD21 > Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 > Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so > > Current Java thread: > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) Hi Chris The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. The code is originally by Werner Almesberger. He gave us permission to use it in rxtx. You might look at what has changed since 1998 in his fuser application. Or you can just do like other OSs and do the following in fuserImp.c JNIEXPORT jstring JNICALL Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv *env, jobject obj, jstring arg) { return (*env)->NewStringUTF(env, "Unknown Application"); } It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. -- Trent Jarvi tjarvi at qang.org From Adrien.TOS at ingenico.com Fri Mar 16 05:11:12 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Fri, 16 Mar 2007 12:11:12 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903CBC312@frsnprexc1.usr.ingenico.loc> Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070316/972ab214/attachment.html From joachim at buechse.de Fri Mar 16 05:13:24 2007 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 16 Mar 2007 12:13:24 +0100 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. From tjarvi at qbang.org Fri Mar 16 16:36:29 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 16:36:29 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Fri Mar 16 16:02:23 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 16 Mar 2007 18:02:23 -0400 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Not all platforms are Unix based. Also mixing native library usage and command-line calls is not an elegant solution, IMHO. One or the other, but not both. Andre On 16-Mar-07, at 07:13 , Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is > trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We >> only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From clayno at hotpop.com Sun Mar 18 22:17:28 2007 From: clayno at hotpop.com (Christopher Layno) Date: Mon, 19 Mar 2007 12:17:28 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi everyone, thank you so much for your replies. they were really helpful. anyway, before i sent the email, my team was already implementing a temporary solution by using joachim's suggestion. we invoked a lsof command from our java code although i share the same concern with trent and andre-john about portability issues. that's why i said it's just temporary. my superiors have yet to approve our bug fix. so my question now is this: is recompiling the rxtx source code the only way to solve this problem? because if it's the only solution, then i think my superiors would rather have a new release from the rxtx community itself that fixes this bug(?) rather than have my team recompile the source code. best regards, chris Trent Jarvi wrote: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. ... It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070318/237463b2/attachment.html From tjarvi at qbang.org Mon Mar 19 16:20:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Mar 2007 16:20:52 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: Hi Chris I can compile a new version after the 21st if you do not feel comfortable doing so. Please send me an email reminder off-line then. On Mon, 19 Mar 2007, Christopher Layno wrote: > hi everyone, > > thank you so much for your replies. they were really helpful. > > anyway, before i sent the email, my team was already implementing a > temporary solution by using joachim's suggestion. > we invoked a lsof command from our java code although i share the same > concern with trent and andre-john about > portability issues. that's why i said it's just temporary. my superiors have > yet to approve our bug fix. > > so my question now is this: is recompiling the rxtx source code the only way > to solve this problem? because if it's the only > solution, then i think my superiors would rather have a new release from the > rxtx community itself that fixes this bug(?) > rather than have my team recompile the source code. > > best regards, > > chris > > Trent Jarvi wrote: > > Hi Joachim > > It would be nice to have that functionality but calling the program > introduces too many issues imho. Explaining to someone why rxtx invoked a > rogue lsof does not sound very interesting. > > On Fri, 16 Mar 2007, Joachim Buechse wrote: > > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: > > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. > > _______________________________________________ > Rxtx mailing list > Rxtx 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 Eric.Arseneau at sun.com Tue Mar 20 11:47:33 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Tue, 20 Mar 2007 10:47:33 -0700 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 Message-ID: <46001E35.9040608@sun.com> Anyone have any experience with RXTX working with JDK 6 on other platforms ? From mm at UDel.Edu Tue Mar 20 12:18:29 2007 From: mm at UDel.Edu (Mike Markowski) Date: Tue, 20 Mar 2007 14:18:29 -0400 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 In-Reply-To: <46001E35.9040608@sun.com> References: <46001E35.9040608@sun.com> Message-ID: <46002575.4000306@udel.edu> Eric Arseneau wrote: > Anyone have any experience with RXTX working with JDK 6 on other platforms ? I'm using 32 bit intel, gentoo linux, jdk6 with no problems. My applications only use a serial port, though, nothing on the parallel port. Mike From falko.guderian at gmx.de Wed Mar 21 08:17:35 2007 From: falko.guderian at gmx.de (Falko Guderian) Date: Wed, 21 Mar 2007 15:17:35 +0100 Subject: [Rxtx] RXTX binaries for SH4 Message-ID: <46013E7F.40102@gmx.de> Dear developers, I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no possiblities to compile the source code. Better, I'm not able to do this at the moment. Can you provide me with rxtxSerial.dll (SH4) in the rxtx-2.1-8-testing version? (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) The reason for the testing version is I need custom baud rates. Thanks for help. Kind regards, Falko Guderian From tjarvi at qbang.org Wed Mar 21 21:38:37 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Mar 2007 21:38:37 -0600 (MDT) Subject: [Rxtx] RXTX binaries for SH4 In-Reply-To: <46013E7F.40102@gmx.de> References: <46013E7F.40102@gmx.de> Message-ID: On Wed, 21 Mar 2007, Falko Guderian wrote: > Dear developers, > > I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no > possiblities to compile the source code. Better, I'm not able to do this > at the moment. Can you provide me with rxtxSerial.dll (SH4) in the > rxtx-2.1-8-testing version? > (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) > > The reason for the testing version is I need custom baud rates. > > Thanks for help. > Hi Falko WinCE binary format is not supported by gcc. That makes compiling limited to those familiar with the WinCE tools. I hope someone is able to provide them for you but it is not likely. WinCE has been compiled by others in the past but rxtx.org builds have never included WinCE. There is some information with the source concerning WinCE builds if you decide to do it. We can share your results too if you like. The source in the WinCE has never been updated for the custom baud rate. That would need changes from the main source I presume. If you look at the source, you will note that Michal Hobot created a mini fork in the source to handle wince but it has not been updated for 3 years. -- Trent Jarvi tjarvi at qbang.org From Adrien.TOS at ingenico.com Thu Mar 22 07:08:55 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Thu, 22 Mar 2007 14:08:55 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Hi everybody, Do you have any comments on this issue? Thanks! AT ________________________________ De : Adrien TOS Envoy? : vendredi 16 mars 2007 12:11 ? : 'rxtx at qbang.org' Cc : Adrien TOS Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070322/2306c538/attachment.html From jeremy.reeve at zen.co.uk Mon Mar 19 07:36:04 2007 From: jeremy.reeve at zen.co.uk (Jeremy S. Reeve) Date: Mon, 19 Mar 2007 13:36:04 +0000 Subject: [Rxtx] rxtx failing to compile on Fedora Core 6 Message-ID: <1174311364.21865.6.camel@d9thc> When trying to compile latest source : rxtx-2.1-7r2 I get the following when running configure: ---------------- checking os.version 2.6.18-1.2200.fc5smp WARNING: configure is having a hard time determining which directory contains the file jni_md.h. Edit Makefile and fix the variable JAVANATINC to point to the correct directory. The following options are available: /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/ /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/linux/ If there are more than one option available the first was selected. WARNING: Kernel include files do not match the current kernel configure: creating ./config.status ------------------------ which seems OK checking the resultant Makefile but when attempting to build with gmake install I get the following output : ---------------------- 34 problems (34 warnings)/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/javah -classpath .:/home/jsr/rxtxsrc/rxtx-2.1-7r2:/home/jsr/rxtxsrc/rxtx-2.1-7r2/src:/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/ext/RXTXcomm.jar -d i686-pc-linux-gnu -jni `(for i in CommDriver CommPortEnumerator CommPortIdentifier CommPort CommPortOwnershipListener Configure I2C I2CPortEvent I2CPortEventListener I2CPort LPRPort NoSuchPortException ParallelPortEvent ParallelPortEventListener ParallelPort PortInUseException Raw RawPortEvent RawPortEventListener RawPort RS485 RS485PortEvent RS485PortEventListener RS485Port RXTXCommDriver RXTXPort RXTXVersion SerialPortEvent SerialPortEventListener SerialPort UnsupportedCommOperationException UnSupportedLoggerException Zystem;do \ if grep > /dev/null native.* \( /home/jsr/rxtxsrc/rxtx-2.1-7r2/./src/$i.java; then \ echo gnu.io.$i; \ fi; \ done)` i686-pc-linux-gnu/gnu_io_CommPortIdentifier.h: No such file or directory make: *** [/home/jsr/rxtxsrc/rxtx-2.1-7r2/gnu/io/CommDriver.class] Error 1 ------------------------ Any ideas or pointers? Regards, Jeremy From tjarvi at qbang.org Sat Mar 24 08:12:54 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 Mar 2007 08:12:54 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > From Adrien.TOS at ingenico.com Sat Mar 24 11:53:22 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Sat, 24 Mar 2007 18:53:22 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> I do not have the threshold setting enabled, I have explicitely disabled it with: port_.disableReceiveThreshold(); I have also run the same tests with the threshold setting enabled, but they also fail in the same way as described below. So it seems there is a problem with timeout handling on Win32? ________________________________ From: rxtx-bounces at qbang.org on behalf of Trent Jarvi Sent: Sat 3/24/2007 3:12 PM To: RXTX Developers and Users Subject: Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 8312 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20070324/f9e39c9b/attachment.bin From greg.johnson at manchester.ac.uk Sun Mar 25 13:41:36 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Sun, 25 Mar 2007 21:41:36 +0200 Subject: [Rxtx] Mac intel weirdness Message-ID: Hi folks, I'm trying to get rxtx to work on my macbook pro with a USB-serial dongle on it. I am using the 2.1-8 code from the CVS (though it seems to report itself as 2.1-7: makes it difficult to prove to oneself that the changes have 'taken'! - line 4210 in SerialImp.c, line 40 in RXTXVersion.java) I am trying the 2.1-8 because of horrible lock problems in 2.1-7. However, the serialport closure code seems to be broken - it won't close because it believes the (previously opened!) port doesn't exist. Here is what I'm trying: 0. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "false" 1. Open a port Serialport serialport = (SerialPort) commportidentifier.open ("test",100); 2. Talk to a device ... 3. Close port serialport.close(); 4. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "true" - why is this? 5. Try to reopen port Serialport serialport2 = (SerialPort) commportidentifier.open("test", 100); throws PortInUseException. I've dug around a bit in the source, and it seems the SerialPort.close () should call the CommPortIdentifier.internalClosePort() (line 67 of CommPort.java). However, I crash out with the NoSuchPortException when getPortIdentifier is called. Which seems quite weird to me, seeing as it is called on this - which was create just beforehand. Does anyone know how to fix this? Cheers, greg From knute at frazmtn.com Sat Mar 24 10:32:38 2007 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 24 Mar 2007 09:32:38 -0700 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc>, Message-ID: <4604F036.17833.135298@knute.frazmtn.com> > >The behavior of timeout depends upon the setting of the threshold. Do you >have the threshold setting? > This is the same bug I reported last fall. There was a fellow that sent me an email asking if it had been fixed. I told him I didn't think so. He got somebody to write a fix for him but I have not been able to contact him again for the actual changes. The inaccurate timeout and the failure of blocking when no timeouts are set is a serious bug in my humble opinion and renders the software unusable for my applications. I'd really like to have an alternative to the Sun comm api but there just isn't one that I know of. -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Mar 26 16:17:00 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 26 Mar 2007 16:17:00 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> Message-ID: >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. From ra85551 at gmail.com Tue Mar 27 10:18:36 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Tue, 27 Mar 2007 20:18:36 +0400 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Ultimately I found a solution. At first, that wasn't actually the VMWare + WinXP + RXTX issue, that was WinXP + RXTX issue. But on pure XP it sometimes workes, sometimes not, while under VMWare I had never seen my snippet working at all. SimpleSnuV1.java would not help me, because there is only one line I missed, and SimpleSnuV1.java also doesn't contain it! It is as follows: serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_OUT | SerialPort.FLOWCONTROL_RTSCTS_IN); Thank you for your attention. -- Pavel Parkhomenko From griff at op.pl Wed Mar 28 01:28:19 2007 From: griff at op.pl (griff@op.pl) Date: Wed, 28 Mar 2007 09:28:19 +0200 Subject: [Rxtx] No blocking read on Windows. Message-ID: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/5d07d571/attachment.html -------------- next part -------------- Hi, I have problem that InputStram.read() (SerialPort)?returns -1 instead blocking and waiting for data. I found that this problem was ?known in 2005 : ? >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > >> Hi Trent >> >> Thanks for the fast response. >> Here's a Q&D test program for the blocking read on windows that just >> attempts to read one byte, and prints the resulting byte. On my system it >> returns -1, where I expect that it keeps waiting for data. >> >This isn't happening on Linux so the bug is in src/termios.c.? I'll have >something this weekend to fix that. I'm using RXTX 2.1.7r2 and the problem still is here. Im using Windows XP and java 1.5 disableReciveTimeout() and disableReciveTreshhold() dont help. ? best regards ? Piotr Zielniok From Adrien.TOS at ingenico.com Wed Mar 28 01:40:46 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Wed, 28 Mar 2007 09:40:46 +0200 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903E88880@frsnprexc1.usr.ingenico.loc> Looking at the code, it seems there is no support for infinite timeout? And maybe the count++ < 20 condition is breaking out of the loop too early? The only condition to break out of the loop should either be the timeout has expired or the number of requested bytes has been received. -----Message d'origine----- De : rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] De la part de Trent Jarvi Envoy? : mardi 27 mars 2007 00:17 ? : RXTX Developers and Users Objet : Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From j.kenneth.gentle at acm.org Wed Mar 28 06:44:15 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 28 Mar 2007 08:44:15 -0400 Subject: [Rxtx] No blocking read on Windows. In-Reply-To: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> References: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> Message-ID: <200703281844.l2SIiITW028614@qbang.org> Just another "ME TOO!" - I'm seeing this problem on Windows XP, jre for windows XP/Embedded. I cranked receiveTimeout up to Integer.MAX_INT, but it doesn't seem to wait that long At 03:28 2007-03-28, you wrote: >Hi, >I have problem that InputStram.read() (SerialPort) returns -1 >instead blocking and waiting for data. I found that this problem >was known in 2005 : > > >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > > > >> Hi Trent > >> > >> Thanks for the fast response. > >> Here's a Q&D test program for the blocking read on windows that just > >> attempts to read one byte, and prints the resulting byte. On my system it > >> returns -1, where I expect that it keeps waiting for data. > >> > > >This isn't happening on Linux so the bug is in src/termios.c. I'll have > >something this weekend to fix that. > >I'm using RXTX 2.1.7r2 and the problem still is here. >Im using Windows XP and java 1.5 >disableReciveTimeout() and disableReciveTreshhold() dont help. > >best regards > >Piotr Zielniok > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From greg.johnson at manchester.ac.uk Wed Mar 28 14:43:29 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Wed, 28 Mar 2007 22:43:29 +0200 Subject: [Rxtx] Cannot close and reopen serial port Message-ID: <377F9765-7A9D-4CE9-9176-FFB63A2594F0@manchester.ac.uk> Dear all, It appears I cannot close a port properly: SerialPort serialport = portid.open("myprog",100); // do some stuff, all works fine serialport.close(); // all seems fine but... SerialPort sp2 = portid.open("myprog",100); throws PortInUseException. And when I dig into the rxtx code, I find in CommPort.java, in close(): CommPortIdentifier cp = CommPortIdentifier.getPortIdentifier(this); (line 64 or there abouts) but this throws a NoSuchPortException which is caught but ignored (line 74ish). Can anyone suggest how this could happen: a port that was valid, opened, and used, throws a NSPE when it comes to closing it? I'm pulling my (remaining) hair out over this one! Cheers, greg PS And thanks for RXTX - it's great to have! PPS (21.-7. winxp/osx both, java 1.5) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/c28852fc/attachment.html From rxtx at vrijheidslaan.net Fri Mar 30 16:52:50 2007 From: rxtx at vrijheidslaan.net (Rob) Date: Fri, 30 Mar 2007 22:52:50 -0000 Subject: [Rxtx] Cvs Question Message-ID: <61896.80.126.150.87.1175295162.squirrel@webmail.provalue.nl> Hi There, Im trying to get the latest version to work on mac osx. Problem is that i can't checkout version 2.1.8. Probably my fault but can some one please give me the alternative commands for: [user at myhost]$ export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot [user at myhost]$ cvs login Thanx, Rob From ra85551 at gmail.com Thu Mar 1 03:47:06 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Thu, 1 Mar 2007 13:47:06 +0300 Subject: [Rxtx] enableReceiveTimeout() issue Message-ID: Hello, world! I found a limitation of 16300 ms for CommPort's enableReceiveTimeout() method, while in original javax.comm docs there are no any references to that. Is that a bug or feature? I actually need longer timeouts sometimees. -- Pavel Parkhomenko From lyon at docjava.com Thu Mar 1 07:54:17 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 01 Mar 2007 09:54:17 -0500 Subject: [Rxtx] parametric singleton design pattern In-Reply-To: References: <22d55aea0702081207q5e7f6785l352d498d6f5f9fb1@mail.gmail.com> <22d55aea0702100034o3bcf42f3j1d1a6257029a67b0@mail.gmail.com> Message-ID: Hi All, I have been thinking about the use of a design pattern to cache resources that are consumed by processes. Toward that end, I have arrived at a parametric singleton design pattern, which I mentioned on this list some time ago. The idea has been published at: http://www.jot.fm/issues/issue_2007_03/column2 I can't help but think that there should be an API available for dealing with the tracking of serial port usage. Perhaps it is a kind of resource manager called the: SerialPortManager basic prototypes already exist in this vain. See, for example: http://www.ce.rit.edu/research/projects/2005_fall/rt_poolsystem/doc/PoolMon/SerialPortManager.html http://www.eventhelix.com/RealtimeMantra/PatternCatalog/serial_port_design_pattern.htm And others shown by a google search on "SerialPortManager" Cheers! - Doug From Eric.Arseneau at sun.com Thu Mar 1 10:15:03 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:15:03 -0800 Subject: [Rxtx] Any known Java 6 issues with RXTX 2.1-7r2 ? Message-ID: <45E70A17.1060206@sun.com> I just did a test on a recent build of Solaris 11 x86 and it seems that I can connect to my serial device fine when Java 5 is the default, but when Java 6 is the default, no go. Any information ? From Eric.Arseneau at sun.com Thu Mar 1 10:19:58 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:19:58 -0800 Subject: [Rxtx] Mac OS X and missing data Message-ID: <45E70B3E.7040908@sun.com> We have a device which is USB based but presents itself as a serial port to a machine. On my MacBook Pro I can get excellent throughput if I get my device to send data as quickly as possible. On the desktop side, if I do an type of disk IO to log the data I get, I end up with some missing data at some point. I hooked up a USB analyzer and did confirm that all the data is sent as expected to the desktop from the device. I found a work around for this, buffer the data in memory and only write the data out when I've received it all. However, when the same code and same device is attempted on a co-workers MacBook Pro (same hardware specs), I get errors and must slow down dramatically the device side's sending of data. Any ideas/recommendations on what I can do to get rid of this error ? From what I can tell, it seems that RXTX is not able to wake up to the interrupts coming in indicating data is ready, quickly enough, is there anything I can do ? From chinkaiw at hotmail.com Fri Mar 2 00:57:43 2007 From: chinkaiw at hotmail.com (Wang Chinkai) Date: Fri, 02 Mar 2007 07:57:43 +0000 Subject: [Rxtx] dynamic detect rs232 port Message-ID: Hi all I have a question about detecting rs232 port dynamicly. I have to aceess some port and detect rs232 port at the same time. Some usb device simulates rs232 port , and I can not know what the port name it gets until it connects,so I have to detect it dynamic,but I have to access another rs232 device at the same time. I found a problem. If I use CommPortIdentifier.getPortIdentifiers() to get new port list , and the other rs232 access function will not close port correctly. So , How can I solve it . Thanks. _________________________________________________________________ ?? 2GB ???? Windows Live Mail ????????????? http://ideas.live.com/programpage.aspx?versionid=5d21c51a-b161-4314-9b0e-4911fb2b2e6d From eu259473 at tele2.it Fri Mar 2 06:16:40 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 02 Mar 2007 14:16:40 +0100 Subject: [Rxtx] rxtx on HP tru 64 unix Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070302/706c7a70/attachment-0001.html From tjarvi at qbang.org Fri Mar 2 08:39:33 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 08:39:33 -0700 (MST) Subject: [Rxtx] rxtx on HP tru 64 unix In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, "Giuseppe Marchese" wrote: > Hi > > I try to install rxtx on hp tru 64 but make fails, > There are somebody that do the same and work. > > > Sorry for may english! > > Hi Giuseppe Could you provide a log of the failure? script ./configure make # use gnu make exit The information will be in the typescript created. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 2 19:56:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 19:56:52 -0700 (MST) Subject: [Rxtx] dynamic detect rs232 port In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, Wang Chinkai wrote: > Hi all > > I have a question about detecting rs232 port dynamicly. > > I have to aceess some port and detect rs232 port at the same time. > Some usb device simulates rs232 port , and I can not know > what the port name it gets until it connects,so I have to detect it > dynamic,but I have to access > another rs232 device at the same time. > > I found a problem. Hi Wang This is a known problem. The code is braindead there. In fact there needs to be events even in a rudamentary way when you add a usb dongle. I'm burried in tasks not far from rxtx but not in rxtx. I can't get to the problem but we would accept patches if you dig into it. [I'm getting to the license question earlier too; I don't have another 10%] -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Fri Mar 2 23:19:01 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 01:19:01 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Hi, Under ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable USB -> serial converter(using virtual com port drivers), with using example code pretty much straight out of http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port opens fine, enumerations all work, etc. My application calls for a large amount of data to be transferred in a short amount of time at 2,000,000 baud. My hardware sends approximately 15,232 bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL converter work fine, and the application works using C++. In C++, I do a hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); to open the port, and a boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); to read the port. The variable buffer fills with the 15238 bytes, and returns. If I do a resultz = is.read(cbuf,0,15238); in java with RXTX where is = new BufferedReader(new InputStreamReader(port.getInputStream())); and where resultz is an int, and cbuf is a char [] cbuf, resultz gets EXACTLY 3968 bytes the first time called. If I call it multiple times, I get roughly 11k total(less than what is sent), never more than the 3968 bytes per is.read() call. My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 bytes. I've played with inputbuffersize, receive threshold, receivetimeout, and so on. The FTDI virtual com port drivers that I'm using are rock solid, and have had zero problems with them using a variety of applications, some of my own, some professionally written, etc. No flow control is used anyplace, no RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. No exceptions are being thrown. What am I doing wrong, and what I can adjust to receive the full 15k bytes in one single read? Thanks! Keith From Eric.Arseneau at sun.com Fri Mar 2 23:32:07 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Fri, 02 Mar 2007 22:32:07 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <45E91667.20501@sun.com> This is the same type of thing that is happening to me on Mac OS X and does not seem to behave the same on different machines. I posted a day or two ago on this with subject "Mac OS X and missing data". Would love to hear if there is a solution to this :) From tjarvi at qbang.org Sat Mar 3 10:54:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 10:54:17 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > Hi, > > Under > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable > USB -> serial converter(using virtual com port drivers), with using example > code pretty much straight out of > http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port > opens fine, enumerations all work, etc. > > My application calls for a large amount of data to be transferred in a short > amount of time at 2,000,000 baud. My hardware sends approximately 15,232 > bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL > converter work fine, and the application works using C++. > > In C++, I do a > > hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, > OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); > > to open the port, and a > > boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); > > to read the port. > > The variable buffer fills with the 15238 bytes, and returns. > > If I do a > > resultz = is.read(cbuf,0,15238); in java with RXTX > > where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > > and where resultz is an int, and cbuf is a char [] cbuf, resultz gets > EXACTLY 3968 bytes the first time called. If I call it multiple times, I get > roughly 11k total(less than what is sent), never more than the 3968 bytes > per is.read() call. > > My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 > bytes. > > I've played with inputbuffersize, receive threshold, receivetimeout, and so > on. The FTDI virtual com port drivers that I'm using are rock solid, and > have had zero problems with them using a variety of applications, some of my > own, some professionally written, etc. No flow control is used anyplace, no > RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. > > No exceptions are being thrown. > > What am I doing wrong, and what I can adjust to receive the full 15k bytes > in one single read? > > Thanks! > Hi Keith I would expect a 20 meg application is going to have different behavior with the OS than a smaller application with respect to the kernel memory managment, schedualing, ... Something subtle could be causing problems. With respect to the recieve timeout and threshold, if you set the timeout to zero and the threshold to the size of data you expect, read should not return until it get that data. You may try with a stand alone application that tests just that with the C/C++ API. If the read is returning with less data when tested for short reads, you have found a bug in the device driver more than likely. The USB dongle vendor would probably be interested in knowing about this. As mentioned, these devices are getting very good; almost bug free. I suspect you found a bug though if you did use the threshold and timeout properly. The missing data is typical when not using flow control. When the OS buffering fills, the hardware will start dropping bytes. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:38:52 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:38:52 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> update: I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now instead of 3968. This makes sense. 128 bytes of overhead + 3968 bytes of data = 4096 transfer size 32 bytes of overhead + 992 bytes of data = 1024 transfer size. 1/4 the data = 1/4 the overhead. I rearranged my reading like so: resultz = is.read(cbuf,0,3968); resultz = is.read(cbuf,3968,3968); resultz = is.read(cbuf,7936,3968); while (!(is.ready())); // wait for ready resultz = is.read(cbuf,11904,3334); and this grabs 15,238 bytes total. BUT, I still have the quandry of the screwed up multi-bytes. I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. Approx 8% of the data. The bad bytes always seem to take the flavor of 0x2018, 0x2019, x2022, x2030, x201d. Are these maybe errors and I don't know what they enumerate to? I still can't believe some other layer isn't handling putting those bytes together all in one stream for me. Thanks Keith ----- Original Message ----- From: "Keith" To: "Bob Jacobsen" ; "RXTX Developers and Users" Sent: Saturday, March 03, 2007 11:26 AM Subject: Re: [Rxtx] is.read() only returning 3968 bytes > Bob, > > > Interesting numerical coincidence is that (max USB transfer) - (what > > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > > needed to transfer that much data. > > I was thinking along the same lines. I don't know USB well, but I do know > that those numbers were close enough to warrant investigating the > relationship between them. > > > I think what you're seeing is the internal buffering of the USB data > > stream. You'll need some form of higher-level buffering to smooth > > that out. > > Shouldn't the InputStreamReader() and BufferedReader() provide this type of > buffering? Isn't that the idea behind those? > > > All hypotheses need to be tested. In this case, a test would be to > > check for missing data. If this idea is right, you'll get _all_ the > > data, but you won't be missing characters. > > I did start looking at the data. -- I'm getting weird results. > > I tried this: > > loopzz = 0; > > for (looptwo = 0; looptwo < 100000; looptwo++) { > while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > > }} > > So I'm reading one character at a time. The good news is that loopzz is > exactly 15238 at the end of the routine, which is perfectly correct. I > picked looptwo value out of thin air. > > The weird results come in terms of the values, the data isn't correct at > least in one case. Look here: > > 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > > This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). > But the 0x89 was replaced by 0x2030. Why the heck would the returned value > be 0x2030?? Why is the returned byte completely out of range? Why the > multibyte return? > > From InputStream in the API: > > read > public abstract int read() > throws IOExceptionReads the next byte of data from the > input stream. The value byte is returned as an int in the range 0 to 255. If > no byte is available because the end of the stream has been reached, the > value -1 is returned. This method blocks until input data is available, the > end of the stream is detected, or an exception is thrown. > Value should be 0-255. > > > In my application time is really critical, reading 1 byte at a time is > probably not going to work. > > Thanks Eric & Bob for looking at this. > > Keith > From tjarvi at qbang.org Sat Mar 3 12:52:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 12:52:27 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > update: > > I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now > instead of 3968. > > This makes sense. > > 128 bytes of overhead + 3968 bytes of data = 4096 transfer size > 32 bytes of overhead + 992 bytes of data = 1024 transfer size. > > 1/4 the data = 1/4 the overhead. > > I rearranged my reading like so: > > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. > Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? > > I still can't believe some other layer isn't handling putting those bytes > together all in one stream for me. > The layer for this in Serial land is flow control. Software and hardware flow control prevent the overruns you observe. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:54:41 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:54:41 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <001a01c75dcd$c8802a70$6600a8c0@jbh757ktruws7g> Trent, Thanks for taking the time to reply. > I would expect a 20 meg application is going to have different behavior > with the OS than a smaller application with respect to the kernel memory > managment, schedualing, ... Something subtle could be causing problems. Well, at least I know the VCP drivers, the OS, etc can handle 2mbps reliably. Without hiccuping or dropping bytes. The C++ code works reliably without flow control. > The missing data is typical when not using flow control. When the OS > buffering fills, the hardware will start dropping bytes. I'm actually not getting MISSING data, I'm getting CORRUPTED data. If you look at my most recent post, I'm getting these bad bytes in place of the correct values: 0x2018, 0x2019, x2022, x2030, x201d. Why would is.read() return values not in the range of 0-255 ? Thanks. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 08:59:14 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 07:59:14 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: At 1:19 AM -0500 3/3/07, Keith wrote: >If I do a > >resultz = is.read(cbuf,0,15238); in java with RXTX > >where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > >and where resultz is an int, and cbuf is a char [] cbuf, resultz gets >EXACTLY 3968 bytes the first time called. If I call it multiple times, I get >roughly 11k total(less than what is sent), never more than the 3968 bytes >per is.read() call. > >My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 >bytes. Interesting numerical coincidence is that (max USB transfer) - (what you get) = 4096-3968 = 128 bytes is (almost) the size of the headers needed to transfer that much data. I think what you're seeing is the internal buffering of the USB data stream. You'll need some form of higher-level buffering to smooth that out. All hypotheses need to be tested. In this case, a test would be to check for missing data. If this idea is right, you'll get _all_ the data, but you won't be missing characters. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 09:26:14 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 11:26:14 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Bob, > Interesting numerical coincidence is that (max USB transfer) - (what > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > needed to transfer that much data. I was thinking along the same lines. I don't know USB well, but I do know that those numbers were close enough to warrant investigating the relationship between them. > I think what you're seeing is the internal buffering of the USB data > stream. You'll need some form of higher-level buffering to smooth > that out. Shouldn't the InputStreamReader() and BufferedReader() provide this type of buffering? Isn't that the idea behind those? > All hypotheses need to be tested. In this case, a test would be to > check for missing data. If this idea is right, you'll get _all_ the > data, but you won't be missing characters. I did start looking at the data. -- I'm getting weird results. I tried this: loopzz = 0; for (looptwo = 0; looptwo < 100000; looptwo++) { while (is.ready()) { cbuf[loopzz] = (char) is.read(); loopzz++; }} So I'm reading one character at a time. The good news is that loopzz is exactly 15238 at the end of the routine, which is perfectly correct. I picked looptwo value out of thin air. The weird results come in terms of the values, the data isn't correct at least in one case. Look here: 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). But the 0x89 was replaced by 0x2030. Why the heck would the returned value be 0x2030?? Why is the returned byte completely out of range? Why the multibyte return? >From InputStream in the API: read public abstract int read() throws IOExceptionReads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown. Value should be 0-255. In my application time is really critical, reading 1 byte at a time is probably not going to work. Thanks Eric & Bob for looking at this. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 14:44:50 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 13:44:50 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: Java's "char" type is Unicode. I think what you're seeing is a bug in the byte -> Unicode translation. 0x2018, 0x2019 are the curly open and close quotes. There used to be (and might still be) bugs in the conversion of these in a couple of libc versions. Some of the ASCII -> ISO and ISO -> ASCII routines were a little over-ambitious with respect to handling the open and close quotes, and tried to convert them to the "curly" form inappropriately. Try _not_ casting it to char. Bob At 11:26 AM -0500 3/3/07, Keith wrote: >Bob, > >> Interesting numerical coincidence is that (max USB transfer) - (what >> you get) = 4096-3968 = 128 bytes is (almost) the size of the headers >> needed to transfer that much data. > >I was thinking along the same lines. I don't know USB well, but I do know >that those numbers were close enough to warrant investigating the >relationship between them. > >> I think what you're seeing is the internal buffering of the USB data >> stream. You'll need some form of higher-level buffering to smooth >> that out. > >Shouldn't the InputStreamReader() and BufferedReader() provide this type of >buffering? Isn't that the idea behind those? > >> All hypotheses need to be tested. In this case, a test would be to >> check for missing data. If this idea is right, you'll get _all_ the >> data, but you won't be missing characters. > >I did start looking at the data. -- I'm getting weird results. > >I tried this: > >loopzz = 0; > >for (looptwo = 0; looptwo < 100000; looptwo++) { >while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > >}} > >So I'm reading one character at a time. The good news is that loopzz is >exactly 15238 at the end of the routine, which is perfectly correct. I >picked looptwo value out of thin air. > >The weird results come in terms of the values, the data isn't correct at >least in one case. Look here: > >0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > >This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). >But the 0x89 was replaced by 0x2030. Why the heck would the returned value >be 0x2030?? Why is the returned byte completely out of range? Why the >multibyte return? > >>From InputStream in the API: > >read >public abstract int read() > throws IOExceptionReads the next byte of data from the >input stream. The value byte is returned as an int in the range 0 to 255. If >no byte is available because the end of the stream has been reached, the >value -1 is returned. This method blocks until input data is available, the >end of the stream is detected, or an exception is thrown. >Value should be 0-255. > > >In my application time is really critical, reading 1 byte at a time is >probably not going to work. > >Thanks Eric & Bob for looking at this. > >Keith > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 15:10:11 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 17:10:11 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Bob said ..... > Java's "char" type is Unicode. I think what you're seeing is a bug > in the byte -> Unicode translation. Bob -- I think you hit the nail on the head. I was just coming to the same realization here. I knew that something funny was going on because the same bytes always got "corrupted." I'm pretty sure its in the InputStreamReader() functionality where the conversion junk is happening. Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. I don't know if simply changing the cast is going to work. Since the conversion is happening upstream (pun intended), I don't think my cast is doing this. Also I think the compiler forced me to use the cast. I'm still playing around, and I'll report back once I nail it down. Thanks!! Keith From tjarvi at qbang.org Sat Mar 3 15:59:46 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 15:59:46 -0700 (MST) Subject: [Rxtx] Win64 rxtx Testers? Message-ID: I have compiled win64 binaries of rxtx. Are there any users interested in testing them? If so, I'll look into putting them on the web site. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Mar 3 15:35:06 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 14:35:06 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: Because of this and similar problems, JMRI does all it's serial IO using +only+ byte values. It's a but of a pain, as Java wants to go to char and int types a little too aggressively, but it does solve the "uncontrolled conversions" problems. Bob At 5:10 PM -0500 3/3/07, Keith wrote: >Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > >Bob -- I think you hit the nail on the head. > >I was just coming to the same realization here. I knew that something funny >was going on because the same bytes always got "corrupted." > >I'm pretty sure its in the InputStreamReader() functionality where the >conversion junk is happening. > >Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > >I don't know if simply changing the cast is going to work. Since the >conversion is happening upstream (pun intended), I don't think my cast is >doing this. Also I think the compiler forced me to use the cast. -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mark at mdsh.com Sun Mar 4 11:01:33 2007 From: mark at mdsh.com (Mark Himsley) Date: Sun, 04 Mar 2007 18:01:33 +0000 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: <5C01AC72C200388815C04982@bedroom.mdsh.local> On 03 March 2007 14:38 -0500 Keith wrote: > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT > consistent. Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? It looks like you need to use DataInputStream and DataOutputStream. -- Mark Himsley From tjarvi at qbang.org Sun Mar 4 11:35:08 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 11:35:08 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" > > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > > * Line #21 - Not sure if you need a (TM) mark for > the term "Sun" > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > OK. I'm going through this today. Some groups ask if rxtx could be under their license also. I think this is a good example of why I resist multiple licenses and focus on why the current license may not be usable by them. The RXTX project is a convergence of hobby and commercial interests. I happen to do both right now. The problem with licensing is we have to stay on top of them as they change. Clearly, adding more licenses will not make this easier. I'm acting as the hobby person today. RXTX always favors the hobby people. But as we move forward, I'm going to need to bring this to lawyers at work and explain to them what is going on. Others here may have to do this also. I don't anticipate problems or unexpected changes. The goal is a consistant, comprehendable and usable license as close to what we have now as possible. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 14:52:10 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 14:52:10 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (1/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: I'm breaking this into two parts. I expect the second part will need more attention. Comments first, then the changed material below. On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > Thanks > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. OK. RXTX for consitent use. java should not be capitalized because it does not only mean Sun [TM] Java [TM]. An example of this not meaning Java is when people use RXTX with GCJ. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". There are not any contributors that are in all of RXTX yet but I did update the comment to try to reflect the current situation without making it a nightmare to maintain. I looked to see how the Linux kernel does it as a reference point. > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" The URL can be problematic. I have done so below with a time reference. GNU does not provide version information in their URLS. I picture this being a problem when the version 3 comes out. > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > This will be corrected when the copy is updated to the version linked below. ---------------- begin proposed material involved -------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. ----------------- end proposed material involved -------------------- I'll be looking at the linking issue again next. That should be all that remains other than including the 2.1 version. Let me know if you have problems with anything here. I do not want to dilute the material I post next with these housekeeping tasks. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 16:08:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 16:08:36 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: For those that are wondering what is going on here, this next bit is the meat of the changes. We agreed a long time ago to put this disclaimer in. We did a so so job. It was in rxtx 2.0, not well written, ... So some groups using rxtx that would like to ship rxtx so users don't need to download, install, go to the mail-list to find why it failed, ... Then their legal teams tell them section 5 paragraph 2 is a show stopper. That was never the intent. Now going through what remains... > and might need a (TM) suffix to make Sun happy. Added disclaimer at the ended 'all trademarks belong...' > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. OK. As you can see I was trying to adjust GNU text there for the LGPL. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. used dynamically linked terminology. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". I tried to address this more upfront with an intent statement. Let me know if you have problems with it. I also tried to make it a little more clear what was derived from the GNU solution by moving the link location closer to GNU's suggestion. > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > Thats the intent. Here is the combined fixes. Note that only the material in /*-- --*/ is being touched. The new GPL license is there but unmodified. ------------------------ begin proposed new license ------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. | | An executable that contains no derivative of any portion of RXTX, but | is designed to work with RXTX by being dynamically linked with it, | is considered a "work that uses the Library" subject to the terms and | conditions of the GNU Lesser General Public License. | | The following has been added to the RXTX License to remove | any confusion about linking to RXTX. We want to allow in part what | section 5, paragraph 2 of the LGPL does not permit in the special | case of linking over a controlled interface. The intent is to add a | Java Specification Request or standards body defined interface in the | future as another exception but one is not currently available. | | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface | | As a special exception, the copyright holders of RXTX give you | permission to link RXTX with independent modules that communicate with | RXTX solely through the Sun Microsytems CommAPI interface version 2, | regardless of the license terms of these independent modules, and to copy | and distribute the resulting combined work under terms of your choice, | provided that every copy of the combined work is accompanied by a complete | copy of the source code of RXTX (the version of RXTX used to produce the | combined work), being distributed under the terms of the GNU Lesser General | Public License plus this exception. An independent module is a | module which is not derived from or based on RXTX. | | Note that people who make modified versions of RXTX are not obligated | to grant this special exception for their modified versions; it is | their choice whether to do so. The GNU Lesser General Public License | gives permission to release a modified version without this exception; this | exception also makes it possible to release a modified version which | carries forward this exception. | | You should have received a copy of the GNU Lesser General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA | All trademarks belong to their respective owners. --------------------------------------------------------------------------*/ The original GNU Lesser General Public License Follows. GNU LESSER GENERAL PUBLIC LICENSE Version 2.1, February 1999 Copyright (C) 1991, 1999 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. [This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence the version number 2.1.] Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This license, the Lesser General Public License, applies to some specially designated software packages--typically libraries--of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below. When we speak of free software, we are referring to freedom of use, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish); that you receive source code or can get it if you want it; that you can change the software and use pieces of it in new free programs; and that you are informed that you can do these things. To protect your rights, we need to make restrictions that forbid distributors to deny you these rights or to ask you to surrender these rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library or if you modify it. For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights. We protect your rights with a two-step method: (1) we copyright the library, and (2) we offer you this license, which gives you legal permission to copy, distribute and/or modify the library. To protect each distributor, we want to make it very clear that there is no warranty for the free library. Also, if the library is modified by someone else and passed on, the recipients should know that what they have is not the original version, so that the original author's reputation will not be affected by problems that might be introduced by others. Finally, software patents pose a constant threat to the existence of any free program. We wish to make sure that a company cannot effectively restrict the users of a free program by obtaining a restrictive license from a patent holder. Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license. Most GNU software, including some libraries, is covered by the ordinary GNU General Public License. This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs. When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library. We call this license the "Lesser" General Public License because it does Less to protect the user's freedom than the ordinary General Public License. It also provides other free software developers Less of an advantage over competing non-free programs. These disadvantages are the reason we use the ordinary General Public License for many libraries. However, the Lesser license provides advantages in certain special circumstances. For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License. In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software. For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU operating system, as well as its variant, the GNU/Linux operating system. Although the Lesser General Public License is Less protective of the users' freedom, it does ensure that the user of a program that is linked with the Library has the freedom and the wherewithal to run that program using a modified version of the Library. The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, whereas the latter must be combined with the library in order to run. GNU LESSER GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License Agreement applies to any software library or other program which contains a notice placed by the copyright holder or other authorized party saying it may be distributed under the terms of this Lesser General Public License (also called "this License"). Each licensee is addressed as "you". A "library" means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables. The "Library", below, refers to any such software library or work which has been distributed under these terms. A "work based on the Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term "modification".) "Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library. Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does. 1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) The modified work must itself be a software library. b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change. c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License. d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful. (For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library. In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. 4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange. If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code. 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables. When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law. If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.) Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself. 6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications. You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things: a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.) b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. c) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution. d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place. e) Verify that the user has already received a copy of these materials or that you have already sent this user a copy. For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute. 7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things: a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above. b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work. 8. You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 9. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Library (or any work based on the Library), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Library or works based on it. 10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties with this License. 11. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply, and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 12. If the distribution and/or use of the Library is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Library under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 13. The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation. 14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Libraries If you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the ordinary General Public License). To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Also add information on how to contact you by electronic and paper mail. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the library, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the library `Frob' (a library for tweaking knobs) written by James Random Hacker. , 1 April 1990 Ty Coon, President of Vice That's all there is to it! ------------------------ end of proposed license ------------------ -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sun Mar 4 16:26:04 2007 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 04 Mar 2007 17:26:04 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <45EB558C.3010609@cox.net> Bob Jacobsen wrote: > Because of this and similar problems, JMRI does all it's serial IO > using +only+ byte values. It's a but of a pain, as Java wants to go > to char and int types a little too aggressively, but it does solve > the "uncontrolled conversions" problems. Anytime that you are reading bytes of data that is not printable, unicode text, in Java, you really need to stay away from the Readers. Use input stream only, or you will see unicode valued byte groups converted to unicode "char" values. Gregg Wonderly From joachim at buechse.de Mon Mar 5 04:23:48 2007 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 5 Mar 2007 12:23:48 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> The behaviour is exactly what you asked for in you code. is = new BufferedReader(new InputStreamReader(port.getInputStream())); Readers return Text (ie unicode chars) not bytes. You instantiate the InputStreamReader without saying which charset you want, which means "platform default". As this is on Windows, it will convert Windows characters to equivalent unicode characters. If you want to read bytes, read bytes not Text. Reading bytes is done with InputStream and BufferedInputStream. BTW: The InputStream and Reader methods that read arrays are not guarenteed to fill up the array. You always have to check what you really got, and advance your index accordingly. A typical "read up to 32k" method looks like this: InputStream is= ... // -- determine the max buffer size int len= is.available(); if (len == 0) { len= 32 * 1024; } // -- read all available data byte[] buffer= new byte[len]; int pos= 0; int read; do { read= is.read(buffer, pos, buffer.length - pos); pos= pos + read; } while (read != -1 && pos < buffer.length); Best regards, Joachim --- Joachim B?chse Phone: +41 44 500 2604 Buechse Consulting Hadlaubsteig 2 CH-8006 Z?rich On 03.03.2007, at 23:10, Keith wrote: > Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > > Bob -- I think you hit the nail on the head. > > I was just coming to the same realization here. I knew that > something funny > was going on because the same bytes always got "corrupted." > > I'm pretty sure its in the InputStreamReader() functionality where the > conversion junk is happening. > > Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > > I don't know if simply changing the cast is going to work. Since the > conversion is happening upstream (pun intended), I don't think my > cast is > doing this. Also I think the compiler forced me to use the cast. > > I'm still playing around, and I'll report back once I nail it down. > > Thanks!! > > Keith > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Mon Mar 5 07:25:46 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 05 Mar 2007 08:25:46 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> Message-ID: <45EC286A.8060608@cox.net> Joachim Buechse wrote: > BTW: The InputStream and Reader methods that read arrays are not > guarenteed to fill up the array. You always have to check what you > really got, and advance your index accordingly. A typical "read up to > 32k" method looks like this: > > InputStream is= ... > // -- determine the max buffer size > int len= is.available(); > if (len == 0) { > len= 32 * 1024; > } > // -- read all available data > byte[] buffer= new byte[len]; > int pos= 0; > int read; > do { > read= is.read(buffer, pos, buffer.length - pos); > pos= pos + read; > } while (read != -1 && pos < buffer.length); > My preferred structure is. byte arr[ len ]; int cnt; int off = 0; while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { off += cnt; } This keeps you from adding -1 to pos when the read returns -1. It also skips out when the read is 0 bytes which, is not a described EOF in InputStream java docs, but is a condition I want to be aware of. Gregg Wonderly From joachim at buechse.de Tue Mar 6 02:52:58 2007 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 6 Mar 2007 10:52:58 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <45EC286A.8060608@cox.net> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: The code I copied was from a file resource reader, it shouldn't really be applied to networking/external IO code. Mea culpa. However aborting when you get 0 from read is not always what you want either (you kind of indicated that already). Some unix java implementations will return 0 if the kernel read was aborted with EINTER, which is rarely the point where you want to abort your read - at least not without further checks. A "complete" solution always depends on the events you need to handle and the time the total read could take in reality. In some cases it's worth checking Thread.isInterrupted() in the loop, some code re-loops on 0 but only a limited number of times, some check a total timeout limit, etc... Best regards, Joachim On 05.03.2007, at 15:25, Gregg Wonderly wrote: > My preferred structure is. > > byte arr[ len ]; > int cnt; > int off = 0; > while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { > off += cnt; > } > > This keeps you from adding -1 to pos when the read returns -1. It > also skips > out when the read is 0 bytes which, is not a described EOF in > InputStream java > docs, but is a condition I want to be aware of. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Mar 6 14:47:44 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 Mar 2007 14:47:44 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: Just FYI, rxtx will usually not break out on EINTER. The code in the native library usually does something close to this: do { read(...) } while ( !done && errno==EINTR ); Obviously there is a little more involved but it will retry on EINTER if not done. On Tue, 6 Mar 2007, Joachim Buechse wrote: > The code I copied was from a file resource reader, it shouldn't > really be applied to networking/external IO code. Mea culpa. > > However aborting when you get 0 from read is not always what you want > either (you kind of indicated that already). Some unix java > implementations will return 0 if the kernel read was aborted with > EINTER, which is rarely the point where you want to abort your read - > at least not without further checks. A "complete" solution always > depends on the events you need to handle and the time the total read > could take in reality. In some cases it's worth checking > Thread.isInterrupted() in the loop, some code re-loops on 0 but only > a limited number of times, some check a total timeout limit, etc... > > Best regards, > Joachim > > On 05.03.2007, at 15:25, Gregg Wonderly wrote: >> My preferred structure is. >> >> byte arr[ len ]; >> int cnt; >> int off = 0; >> while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { >> off += cnt; >> } >> >> This keeps you from adding -1 to pos when the read returns -1. It >> also skips >> out when the read is 0 bytes which, is not a described EOF in >> InputStream java >> docs, but is a condition I want to be aware of. >> >> Gregg Wonderly >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 gjhanna at gmail.com Thu Mar 8 13:42:52 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Fri, 9 Mar 2007 09:42:52 +1300 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? Message-ID: I've just struck an issue using rxtx in a multi-threaded environment: If I have 3 threads trying to open *the same* comm-port I get a deadlock in CommPortIdentifier.open If I have just 2, it works fine - I get a PortInUseException which is nice and I can handle it. The 3 thread->deadlock thing is causing me issues. (Sample code below). This is from the java thread-dump Found one Java-level deadlock: ============================= "Thread-2": waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object ), which is held by "Thread-1" "Thread-1": waiting to lock monitor 0x0003e9cc (object 0x2450e108, a gnu.io.CommPortIdentifier), which is held by "Thread-2" Java stack information for the threads listed above: =================================================== "Thread-2": at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:329) - waiting to lock <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) "Thread-1": at java.lang.Object.wait(Native Method) - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) - locked <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) (Apart from this, rxtx is working fantastically for us). I'm thinking I'll have to implement some sort of locking mechanism that *doesn't* use java synchronization to prevent this situation. (Which doesn't sound like a good idea to me). Any ideas? Thanks, Greg Hanna ============= RXTXLockTest.java ======================================== import gnu.io.CommPort; import gnu.io.CommPortIdentifier; /** * @author Greg Hanna * Minimal code to create a deadlock with rxtx in multithreaded open */ public class RXTXLockTest { public static void main(String[] args) { try { CommPortIdentifier cpiCom1 = CommPortIdentifier.getPortIdentifier ("COM14"); OpenThread t1 = new OpenThread (" one ", cpiCom1); OpenThread t2 = new OpenThread (" two ", cpiCom1); OpenThread t3 = new OpenThread (" 003 ", cpiCom1); t1.start(); t2.start(); t3.start(); // comment this out and it runs with (expected) PortInUseException } catch (Exception e) { e.printStackTrace(); } } } class OpenThread extends Thread { String name; CommPortIdentifier cpi; CommPort cp; public OpenThread (String name, CommPortIdentifier cpi) { this.name = name; this.cpi = cpi; System.out.println (System.currentTimeMillis() + name + " thread created"); } public void run () { try { System.out.println (System.currentTimeMillis() + name + " opening"); cp = cpi.open(name, 2000); System.out.println (System.currentTimeMillis() + name + " opened - sleeping"); sleep (2000); // do the serial comms with the device. System.out.println (System.currentTimeMillis() + name + " slept - closing"); cp.close(); System.out.println (System.currentTimeMillis() + name + " closed - exiting"); } catch (Exception e) { System.out.println ("Error in thread: " + name ); e.printStackTrace(); } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070308/d9a163c5/attachment-0001.html From eu259473 at tele2.it Fri Mar 9 02:46:20 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 09 Mar 2007 10:46:20 +0100 Subject: [Rxtx] rxtx: tru64 unix make fails Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070309/3b654523/attachment-0001.html From lyon at docjava.com Fri Mar 9 03:58:32 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 Mar 2007 05:58:32 -0500 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi All, The deadlock issue is one that I have been thinking about for some time now. It seems to me that we need a resource manager that enables assignment to a known process. The one thing that seems important about serial ports is that two applications should not use the same serial port at the same time. When this happens, it throws an exception. OK. The exception is a response to a lock condition that arises from an unavailable resource. An abstract implementation (not born of native methods) might assign a serial port to an application, until the application releases it (or is forced to release it by some kill mechanism). Some resources (like a registry) can be reused. But others, like the serial port, cannot. In the case of the serial port, we would like, I think, to have the flyweight design pattern without sharing and with object assignment tracking. A means of breaking deadlock (like a leasing mechanism) seems very useful, to me. My guess is that we can serialize the state of the Parametric Singleton Pattern (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) into the Preferences of the System. Preferences.systemRoot() might help with that. When a resource is checked out, the lease time and owner are listed. A thread that does this can be killed, but applications outside of Java are problematic. There is a compelling problem here. It is not just serial ports. Sound cards, cameras, microphones, files, tape drives, etc. All are consumed resources that are assigned to an application (or user) and deprive other applications, or users, from use. What, if anything, should we do? At present we throw PortInUseExceptions. Is that it? Can we do better? OK, the port is in use. Now what? Do I have to be root to go remove lock files and kill applications? Is there a better way? Thanks! - Doug >I've just struck an issue using rxtx in a multi-threaded environment: > >If I have 3 threads trying to open *the same* >comm-port I get a deadlock in >CommPortIdentifier.open >If I have just 2, it works fine - I get a >PortInUseException which is nice and I can >handle it. > >The 3 thread->deadlock thing is causing me issues. >(Sample code below). > >This is from the java thread-dump > >Found one Java-level deadlock: >============================= >"Thread-2": > waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), > which is held by "Thread-1" >"Thread-1": > waiting to lock monitor 0x0003e9cc (object >0x2450e108, a gnu.io.CommPortIdentifier ), > which is held by "Thread-2" > >Java stack information for the threads listed above: >=================================================== >"Thread-2": > at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) > - waiting to lock <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) >"Thread-1": > at java.lang.Object.wait(Native Method) > - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) > - locked <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) > > >(Apart from this, rxtx is working fantastically for us). > >I'm thinking I'll have to implement some sort of >locking mechanism that *doesn't* use java >synchronization to prevent this situation. >(Which doesn't sound like a good idea to me). > >Any ideas? > >Thanks, > >Greg Hanna > >============= RXTXLockTest.java ======================================== > >import gnu.io.CommPort; >import gnu.io.CommPortIdentifier; > >/** > * @author Greg Hanna > * Minimal code to create a deadlock with rxtx in multithreaded open > */ >public class RXTXLockTest { > ? > ?public static void main(String[] args) { > ?try { > ?CommPortIdentifier cpiCom1 = >CommPortIdentifier.getPortIdentifier ("COM14"); > ?OpenThread t1 = new OpenThread (" one ", cpiCom1); > ?OpenThread t2 = new OpenThread (" two ", cpiCom1); > ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); > ?t1.start(); > ?t2.start(); > ?t3.start(); // comment this out >and it runs with (expected) PortInUseException > ?} catch (Exception e) { > ?e.printStackTrace(); > ?} > ?} >} > >class OpenThread extends Thread { > ?String name; > ?CommPortIdentifier cpi; > ?CommPort cp; > ?public OpenThread (String name, CommPortIdentifier cpi) { > ? this.name = name; > ?this.cpi = cpi; > ?System.out.println >(System.currentTimeMillis() + name + " thread >created"); > ?} > ?public void run () { > ?try { > ?System.out.println >(System.currentTimeMillis() + name + " opening"); > ?cp = cpi.open(name, 2000); > ?System.out.println >(System.currentTimeMillis() + name + " opened - >sleeping"); > ?sleep (2000); // do the serial comms with the device. > ?System.out.println >(System.currentTimeMillis() + name + " slept - >closing"); > ?cp.close(); > ?System.out.println >(System.currentTimeMillis() + name + " closed - >exiting"); > ?} catch (Exception e) { > System.out.println ("Error in thread: " + name ); > ?e.printStackTrace(); > ?} > ?} >} > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Mar 9 06:37:45 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 Mar 2007 06:37:45 -0700 (MST) Subject: [Rxtx] rxtx: tru64 unix make fails In-Reply-To: References: Message-ID: On Fri, 9 Mar 2007, "Giuseppe Marchese" wrote: > Sorry for delay. > ? > This is log for ./configure and make > error. > ? > thanks for attention > ? > Make: '%.java,$(TOP)/$(CLASSDEST)/%.class,$(wildcard $(SPATH)/*.java)': extra chars.? > Stop. > Hi Giuseppe You need to use GNU make with the Makefile. I suspect the tru64 make is not happy with those rules. > configure: exit 0 Looks like configure is fairly happy. From tjarvi at qbang.org Sat Mar 10 07:43:51 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 07:43:51 -0700 (MST) Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi Doug I have very little time to look into this further but what we could do is open up an rxtx 3 devel branch in which a proof of concept could be worked on. It could be the proof of concept for a JSR others including Sun could look at/work on or parts of it could be recycled in a JSR. I'm working very hard on rxtx right now but it does not show. I'm looking at win64, mac intel/ppc, usb bluetooth and usb serial dongles. Some are going to be more tested than others but they are all on the plate. I'll be pushing all the fixes upstream when they are done. So I'm very busy in 2.1 but we could open a new branch. On Fri, 9 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > The deadlock issue is one that I have been thinking about > for some time now. > It seems to me that we need a resource manager that enables assignment > to a known process. > > The one thing that seems important about serial > ports is that two applications should not use the > same serial port at the same time. When this > happens, it throws an exception. > OK. > > The exception is a response to a lock condition that > arises from an unavailable resource. > > An abstract implementation (not born of native methods) might > assign a serial port to an application, until the > application releases it (or is forced to release > it by some kill mechanism). > > Some resources (like a registry) can be reused. > But others, like the serial port, > cannot. > > In the case of the serial port, we would like, I think, to > have the flyweight design pattern > without sharing and with object assignment tracking. > A means of breaking deadlock (like a leasing > mechanism) seems very useful, to me. > > My guess is that we can serialize the state of the Parametric Singleton Pattern > (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) > into the Preferences of the System. Preferences.systemRoot() might help > with that. When a resource is checked out, the lease time and owner are > listed. A thread that does this can be killed, but applications outside of Java > are problematic. > > There is a compelling problem here. It is not just serial ports. > Sound cards, cameras, microphones, files, tape drives, etc. All are consumed > resources that are assigned to an application (or > user) and deprive other applications, > or users, from use. > > What, if anything, should we do? At present we throw PortInUseExceptions. > Is that it? > Can we do better? > OK, the port is in use. Now what? > Do I have to be root to go remove lock files and kill applications? > Is there a better way? > > Thanks! > - Doug > >> I've just struck an issue using rxtx in a multi-threaded environment: >> >> If I have 3 threads trying to open *the same* >> comm-port I get a deadlock in >> CommPortIdentifier.open >> If I have just 2, it works fine - I get a >> PortInUseException which is nice and I can >> handle it. >> >> The 3 thread->deadlock thing is causing me issues. >> (Sample code below). >> >> This is from the java thread-dump >> >> Found one Java-level deadlock: >> ============================= >> "Thread-2": >> waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), >> which is held by "Thread-1" >> "Thread-1": >> waiting to lock monitor 0x0003e9cc (object >> 0x2450e108, a gnu.io.CommPortIdentifier ), >> which is held by "Thread-2" >> >> Java stack information for the threads listed above: >> =================================================== >> "Thread-2": >> at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) >> - waiting to lock <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> "Thread-1": >> at java.lang.Object.wait(Native Method) >> - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) >> - locked <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> >> >> (Apart from this, rxtx is working fantastically for us). >> >> I'm thinking I'll have to implement some sort of >> locking mechanism that *doesn't* use java >> synchronization to prevent this situation. >> (Which doesn't sound like a good idea to me). >> >> Any ideas? >> >> Thanks, >> >> Greg Hanna >> >> ============= RXTXLockTest.java ======================================== >> >> import gnu.io.CommPort; >> import gnu.io.CommPortIdentifier; >> >> /** >> * @author Greg Hanna >> * Minimal code to create a deadlock with rxtx in multithreaded open >> */ >> public class RXTXLockTest { >> ? >> ?public static void main(String[] args) { >> ?try { >> ?CommPortIdentifier cpiCom1 = >> CommPortIdentifier.getPortIdentifier ("COM14"); >> ?OpenThread t1 = new OpenThread (" one ", cpiCom1); >> ?OpenThread t2 = new OpenThread (" two ", cpiCom1); >> ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); >> ?t1.start(); >> ?t2.start(); >> ?t3.start(); // comment this out >> and it runs with (expected) PortInUseException >> ?} catch (Exception e) { >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> class OpenThread extends Thread { >> ?String name; >> ?CommPortIdentifier cpi; >> ?CommPort cp; >> ?public OpenThread (String name, CommPortIdentifier cpi) { >> ? this.name = name; >> ?this.cpi = cpi; >> ?System.out.println >> (System.currentTimeMillis() + name + " thread >> created"); >> ?} >> ?public void run () { >> ?try { >> ?System.out.println >> (System.currentTimeMillis() + name + " opening"); >> ?cp = cpi.open(name, 2000); >> ?System.out.println >> (System.currentTimeMillis() + name + " opened - >> sleeping"); >> ?sleep (2000); // do the serial comms with the device. >> ?System.out.println >> (System.currentTimeMillis() + name + " slept - >> closing"); >> ?cp.close(); >> ?System.out.println >> (System.currentTimeMillis() + name + " closed - >> exiting"); >> ?} catch (Exception e) { >> System.out.println ("Error in thread: " + name ); >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 mm at UDel.Edu Sat Mar 10 14:48:32 2007 From: mm at UDel.Edu (Mike Markowski) Date: Sat, 10 Mar 2007 16:48:32 -0500 Subject: [Rxtx] rxtx and Sun's comm api Message-ID: <45F327B0.2060004@udel.edu> Hi all, I joined the list a few days ago and apologize for what is likely a frequently asked question, though I haven't yet found it anywhere. I learned about rxtx.org through the readme on Sun's version 2 of their comms api. They give recommendations in that readme regarding how a better comms api should be written. Is this the aim of rxtx.org? I wrote an app on my linux box using the Sun comms api (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the fact that only linux and Solaris are supported. So I'm glad to find rxtx.org and am just reading up on how make the conversion so Windows users will be able to run the program as well. At the same time I'm just curious if rxtx.org and Sun are both heading in the same direction. Thanks for any background or historical info. Feel free to point me to any www pages if my googling has just completely missed the target! Thanks again, Mike From tjarvi at qbang.org Sat Mar 10 15:35:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 15:35:25 -0700 (MST) Subject: [Rxtx] rxtx and Sun's comm api In-Reply-To: <45F327B0.2060004@udel.edu> References: <45F327B0.2060004@udel.edu> Message-ID: On Sat, 10 Mar 2007, Mike Markowski wrote: > Hi all, > > I joined the list a few days ago and apologize for what is likely a > frequently asked question, though I haven't yet found it anywhere. I > learned about rxtx.org through the readme on Sun's version 2 of their > comms api. They give recommendations in that readme regarding how a > better comms api should be written. Is this the aim of rxtx.org? > > I wrote an app on my linux box using the Sun comms api > (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the > fact that only linux and Solaris are supported. So I'm glad to find > rxtx.org and am just reading up on how make the conversion so Windows > users will be able to run the program as well. At the same time I'm > just curious if rxtx.org and Sun are both heading in the same direction. > > Thanks for any background or historical info. Feel free to point me to > any www pages if my googling has just completely missed the target! > I do not have any news (good or bad) concerning RXTX and Sun working together but perhaps others here do. The main goal of RXTX is to expose POSIX termios interfaces to java users. The future support of javax.comm is questionable. We do not have resources for everything. gnu.io (RXTX 2.1) will be supported going forward and functions the same as CommAPI 2.0. If you have control of the source code you are working with, I would not advise using CommAPI 2.0 javax.comm. We do support CommAPI 2.0 javax.comm for older applications but I do not think that will last much longer for practical reasons. The download interest in CommAPI 2.0 javax.comm support is becomming negligible on this end. There has been discussion of a JSR effort but I do not know of any status change since it was mentioned. One problem with a JSR is that even a light weight process is going to be difficult for RXTX at this time. Maybe that will change in the future but then again it may not. For now, we are just going forward 'as is' in rxtx 2.1 with package gnu.io while trying as a secondary effort to backport the changes to rxtx 2.0 for javax.comm support for users that do not have a choice. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Mar 11 07:19:40 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 11 Mar 2007 08:19:40 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: Hi All, I have been a proponent of a JSR that makes use of RXTX. I have executed the proper agreements with Sun. At this point we are in the: Early Draft Review of Draft Specifications Stage. The best thing to do is to enter the quiet period and create a specification. The question of exactly how we, as a group, want to approach this problem, remains open. Typically, we should have both a specification and a reference implementation. Thus, it would be to our best advantage to have a nice, stable, cross platform RXTX distro that adheres to the groups specification. Now, from a specification standpoint, my personal view on the matter is that we create a series of interfaces, with nice documentation (or at least javadoc). Is this a good idea? Should we have a pure interface specification for the communication API? There are several issues, in my mind, which still weigh on us. Hot-pluggable dongles, long discovery process on pop-up ports, lack of uniformity on device names, lack of uniformity on locking, a precise understanding of how the SerialPortResourceManager works (or even if we should have one). The more questions we answer in our reference implementation, the better our specification will get. RXTX is a good working prototype, but, I don't know if that is what we want to use for a specification. Here is what I have for a CommPortInterface: */ public interface CommPortInterface { /** * @return a string representation of this port. */ String toString(); /** * Gets the name of the communications port. This name should correspond to * something the user can identify, like the label on the hardware. * @return name of the port */ String getName(); /** * @return an input stream that can be used to read data from the * communications port. If the port doesn't support reading data, this * method returns null. *

* The blocking behaviour of this input stream depends on the threshold * and timeout values, as shown below for a read buffer size of n * bytes: * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ThresholdTimeoutBlocking behaviour
StateValueStateValue
disableddisabledblock until data is available
enabledm bytesdisabledblock until min(m, n) bytes are available
disabledenabledt msblock for t ms or until data is available
enabledm bytesenabledt msblock for t ms or until min(m, n) bytes are * available
* @throws java.io.IOException */ InputStream getInputStream() throws IOException; /** * @return an output stream that can be used to send data to the * communications port. If the port doesn't support sending data, this * method returns null. * @throws java.io.IOException */ OutputStream getOutputStream() throws IOException; /** * Closes this communications port. * All PortOwnershipListeners will be? * notified of this change of ownership. Further method calls on this? * object will throw IllegalStateException. Further calls on the? * associated InputStream or OutputStream will throw IOException. *

* Close does not block. Undelivered data is discarded. Blocked read and? * write operations are aborted if the underlying operating systems? * supports an IO abort mechanism. To await the delivery of undelivered? * data call OutputStream.flush() or OutputStream.close() before calling? * Port.close(). */ void close(); /** * Enables receive threshold. * When the specified threshold number of bytes are retrieved, read will * return immediately. * * @param thresh the number of bytes in the input buffer * @throws gnu.io.UnsupportedCommOperationException * if receive threshold is * not supported by the driver * @see #disableReceiveThreshold */ void enableReceiveThreshold(int thresh) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive threshold. * * @see #enableReceiveThreshold */ void disableReceiveThreshold(); /** * @return true if receive threshold is enabled. * * @see #enableReceiveThreshold */ boolean isReceiveThresholdEnabled(); /** * @return the receive threshold value. If receive threshold is diabled * or not supported, this value is meaningless. * * @see #enableReceiveThreshold */ int getReceiveThreshold(); /** * Enables receive timeout. * When the specified number of milliseconds have elapsed, read will * return immediately. * * @param rcvTimeout the number of milliseconds to block for * @throws gnu.io.UnsupportedCommOperationException * if receive timeout is * not supported by the driver * @see #disableReceiveTimeout */ void enableReceiveTimeout(int rcvTimeout) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive timeout. * * @see #enableReceiveTimeout */ void disableReceiveTimeout(); /** * @return true if receive timeout is enabled. * * @see #enableReceiveTimeout */ boolean isReceiveTimeoutEnabled(); /** * @return the receive timeout value. If receive timeout is diabled * or not supported, this value is meaningless. * * @see #enableReceiveTimeout */ int getReceiveTimeout(); /** * Enables receive framing. * The supplied byte value in the input suggests the end of the received * frame, and read returns immediately. Only the low 8 bits of the * supplied value are significant. * * @param framingByte the frame delimiter * @throws gnu.io.UnsupportedCommOperationException * if receive framing is * not supported by the driver * @see #disableReceiveFraming */ void enableReceiveFraming(int framingByte) throws UnsupportedCommOperationException; /** * Disables receive framing. * * @see #enableReceiveFraming */ void disableReceiveFraming(); /** * @return true if receive framing is enabled. * * @see #enableReceiveFraming */ boolean isReceiveFramingEnabled(); /** * @return true if receive framing byte. If receive framing is diabled * or not supported, this value is meaningless. * * @see #enableReceiveFraming */ int getReceiveFramingByte(); /** * Sets the input buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setInputBufferSize(int size); /** * @return the input buffer size. * The driver may choose not to report correct values. */ int getInputBufferSize(); /** * Sets the output buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setOutputBufferSize(int size); /** * @return the output buffer size. * The driver may choose not to report correct values. */ int getOutputBufferSize(); } What do you think of that? Note the wishy washy nature of the spec: The driver may choose to ignore this method. Is that good enough for us? Thanks! - Doug From ra85551 at gmail.com Sun Mar 11 08:44:45 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Sun, 11 Mar 2007 17:44:45 +0300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hello, world! I am writing application that communicates with modem via AT commands. My OS is Linux Kubuntu Feisty Herd, to ensure that my application will run properly under Windows XP I installed VMWare server. When I tried to send AT command and evaluate modem answer under WinXP @ VMWare server, I actually didn't receive anything. I think that VM settings are right, because I do can communicate with modem by using standard HyperTerminall as well as I can do on native Windows. So, why RXTX doesn't work under VM, but works under Linux and pure Windows XP (i tested it there) well? The send/receive method code follows. private String sendATCommand(String command, final String waitFor, final boolean isRegex, boolean isAddCRLF, long timeout) throws BeaconConnectException { final long POLL_PERIOD = 100; final int BUFFER_SIZE = 512; final byte[] buffer = new byte[BUFFER_SIZE]; final InputStream serialInput; final OutputStream serialOutput; try { serialInput = serialPort.getInputStream(); if (command != null) { serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } } catch (IOException e) { throw new MyException("serial I/O error"); } TimerTask task = new TimerTask() { int offset = 0; int bytesRead; public synchronized void run() { try { if (serialInput.available() > 0) { bytesRead = serialInput.read(buffer, offset, BUFFER_SIZE - offset); } else { return; } } catch (IOException e) { // do nothing - maybe next time we'll read something } offset += bytesRead; if (waitFor != null) { String temporary = new String(buffer, 0, offset).trim(); if (isRegex && temporary.matches(waitFor) || temporary.contains(waitFor)) { cancel(); notify(); } } } }; Timer timer = new Timer(); timer.schedule(task, POLL_PERIOD, POLL_PERIOD); synchronized (task) { try { task.wait(timeout); task.cancel(); } catch (InterruptedException e) { } } //Cut off leading and trailing CRs, LFs and zeroes String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); System.out.println(response); return response; } -- Pavel Parkhomenko From tjarvi at qbang.org Sun Mar 11 11:48:22 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:48:22 -0600 (MDT) Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: On Sun, 11 Mar 2007, Pavel Parkhomenko wrote: > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. > > private String sendATCommand(String command, final String waitFor, > final boolean isRegex, boolean isAddCRLF, long timeout) > throws BeaconConnectException > { > final long POLL_PERIOD = 100; > final int BUFFER_SIZE = 512; > final byte[] buffer = new byte[BUFFER_SIZE]; > final InputStream serialInput; > final OutputStream serialOutput; > try > { > serialInput = serialPort.getInputStream(); > if (command != null) > { > serialOutput = serialPort.getOutputStream(); > if (isAddCRLF) > { > command += "\r\n"; > } > System.out.println(command); > serialOutput.write(command.getBytes()); > } > } > catch (IOException e) > { > throw new MyException("serial I/O error"); > } > > TimerTask task = new TimerTask() > { > int offset = 0; > int bytesRead; > public synchronized void run() > { > try > { > if (serialInput.available() > 0) > { > bytesRead = serialInput.read(buffer, offset, > BUFFER_SIZE - offset); > } > else > { > return; > } > } > catch (IOException e) > { > // do nothing - maybe next time we'll read something > } > offset += bytesRead; > if (waitFor != null) > { > String temporary = new String(buffer, 0, offset).trim(); > if (isRegex && temporary.matches(waitFor) || > temporary.contains(waitFor)) > { > cancel(); > notify(); > } > } > } > }; > > Timer timer = new Timer(); > timer.schedule(task, POLL_PERIOD, POLL_PERIOD); > synchronized (task) { > try > { > task.wait(timeout); > task.cancel(); > } > catch (InterruptedException e) > { > } > } > //Cut off leading and trailing CRs, LFs and zeroes > String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); > System.out.println(response); > return response; > } > > > Hi Pavel VMWare should not be a problem. I've used it in the past - though not with a modem. Make sure nothing else is using the modem. Then look in the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an example that should work. Note that modems could care less what OS is on top. If you are trying to match new lines to the OS and sending it to the mode for AT commands, thats probably a mistake. Also it would not hurt to print out the individual bytes that you are sending to make sure they did not get mangled along the path. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 11:55:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:55:48 -0600 (MDT) Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: On Sun, 11 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > I have been a proponent of a JSR that makes > use of RXTX. I have executed the proper agreements with Sun. > > At this point we are in the: > Early Draft Review of Draft Specifications Stage. > > The best thing to do is to enter the quiet period and create > a specification. The question of exactly how we, as a group, > want to approach this problem, remains open. > > Typically, we should have both a specification and a reference > implementation. Thus, it would be to our best advantage to have > a nice, stable, cross platform RXTX distro that adheres to the > groups specification. > > Now, from a specification standpoint, my personal view on the matter is > that we create a series of interfaces, with nice documentation (or at least > javadoc). > > Is this a good idea? Should we have a pure interface specification for > the communication API? > > There are several issues, in my mind, which still weigh on us. > Hot-pluggable dongles, long discovery process on pop-up ports, > lack of uniformity on device names, lack of uniformity on locking, > a precise understanding of how the SerialPortResourceManager > works (or even if we should have one). > > The more questions we answer in our reference implementation, the > better our specification will get. RXTX is a good working prototype, > but, I don't know if that is what we want to use for a specification. > > Here is what I have for a CommPortInterface: > */ > public interface CommPortInterface { Hi Doug, I can start going through the method interfaces later this week and giving feedback. I would suggest that the JSR should not be too generic in nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel drivers that intend to look like EIA232 ports at the kernel driver level. some ideas: EIA232PortInterface TermiosInterface SerialPortInterface Something that differentiates this from thing like USB, I2C, ... which should not have to deal with legacy serial claiming to be the comm api. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 12:52:19 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 12:52:19 -0600 (MDT) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: No news is good news with these posts. I'll start the process of pinging legal a week from Monday on my end if nobody has objections to the proposal. I just want to make sure everyone has time to raise objections. Obviously, anyone can fork from a previous version if they don't like the new license. I suspect we can avoid that though. On Sun, 4 Mar 2007, Trent Jarvi wrote: > > For those that are wondering what is going on here, this > next bit is the meat of the changes. We agreed a long time > ago to put this disclaimer in. We did a so so job. It was > in rxtx 2.0, not well written, ... So some groups using > rxtx that would like to ship rxtx so users don't need to > download, install, go to the mail-list to find why it failed, > ... Then their legal teams tell them section 5 paragraph 2 > is a show stopper. > > That was never the intent. > > > Now going through what remains... > >> and might need a (TM) suffix to make Sun happy. > > Added disclaimer at the ended 'all trademarks belong...' > >> * Line #15ff - static vs. dynamic linking - you did >> not transcribe the text from the "controlled >> interface exception" when writing this text - and >> this was good so, because these terms originally >> refer to the GPL rather than the LGPL. I think though, >> that these 4 lines are the most important ones and >> should thus be really really clear. I hope that I >> meet your original intent with the following >> suggestions: >> 1.) Instead of "A program.." it would be better to >> say "An exectuable.." in order to be closer to >> the LGPL text. > > OK. As you can see I was trying to adjust GNU text there > for the LGPL. > >> 2.) It would be better to say .. "by being dynamically >> linked with it" to clearly indicate that dynamic >> linking is meant. The matter of compilation is >> already covered by the LGPL so mentioning it again >> just leads to confusion. > > used dynamically linked terminology. > >> 3.) It would be better to say .. "is considered a >> work that uses the library in contrast to section >> 5 of the LGPL, so the terms of the LGPL do not >> apply to the resulting executable". > > I tried to address this more upfront with an intent statement. > Let me know if you have problems with it. I also tried to > make it a little more clear what was derived from the GNU > solution by moving the link location closer to GNU's suggestion. > >> >> Note that LGPL section 5 says: ..."is called a >> "work that uses the Library". Such a work, in isolation, >> is not a derivative work of the Library, and therefore >> falls outside the scope of this License." >> The next paragraph of the LGPL is exactly the problematic >> one that I hope is clarified by the exception terms you >> give. >> > > Thats the intent. Here is the combined fixes. Note that only the > material in /*-- --*/ is being touched. The new GPL license is > there but unmodified. > > > ------------------------ begin proposed new license ------------------- > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Lesser General Public > | License as published by the Free Software Foundation; either > | version 2.1 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Lesser General Public License for more details. > | > | An executable that contains no derivative of any portion of RXTX, but > | is designed to work with RXTX by being dynamically linked with it, > | is considered a "work that uses the Library" subject to the terms and > | conditions of the GNU Lesser General Public License. > | > | The following has been added to the RXTX License to remove > | any confusion about linking to RXTX. We want to allow in part what > | section 5, paragraph 2 of the LGPL does not permit in the special > | case of linking over a controlled interface. The intent is to add a > | Java Specification Request or standards body defined interface in the > | future as another exception but one is not currently available. > | > | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface > | > | As a special exception, the copyright holders of RXTX give you > | permission to link RXTX with independent modules that communicate with > | RXTX solely through the Sun Microsytems CommAPI interface version 2, > | regardless of the license terms of these independent modules, and to copy > | and distribute the resulting combined work under terms of your choice, > | provided that every copy of the combined work is accompanied by a complete > | copy of the source code of RXTX (the version of RXTX used to produce the > | combined work), being distributed under the terms of the GNU Lesser General > | Public License plus this exception. An independent module is a > | module which is not derived from or based on RXTX. > | > | Note that people who make modified versions of RXTX are not obligated > | to grant this special exception for their modified versions; it is > | their choice whether to do so. The GNU Lesser General Public License > | gives permission to release a modified version without this exception; this > | exception also makes it possible to release a modified version which > | carries forward this exception. > | > | You should have received a copy of the GNU Lesser General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > | All trademarks belong to their respective owners. > --------------------------------------------------------------------------*/ > > The original GNU Lesser General Public License Follows. > > > GNU LESSER GENERAL PUBLIC LICENSE > Version 2.1, February 1999 > > Copyright (C) 1991, 1999 Free Software Foundation, Inc. > 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > Everyone is permitted to copy and distribute verbatim copies > of this license document, but changing it is not allowed. > > [This is the first released version of the Lesser GPL. It also counts > as the successor of the GNU Library Public License, version 2, hence > the version number 2.1.] > > Preamble > > The licenses for most software are designed to take away your > freedom to share and change it. By contrast, the GNU General Public > Licenses are intended to guarantee your freedom to share and change > free software--to make sure the software is free for all its users. > > This license, the Lesser General Public License, applies to some > specially designated software packages--typically libraries--of the > Free Software Foundation and other authors who decide to use it. You > can use it too, but we suggest you first think carefully about whether > this license or the ordinary General Public License is the better > strategy to use in any particular case, based on the explanations below. > > When we speak of free software, we are referring to freedom of use, > not price. Our General Public Licenses are designed to make sure that > you have the freedom to distribute copies of free software (and charge > for this service if you wish); that you receive source code or can get > it if you want it; that you can change the software and use pieces of > it in new free programs; and that you are informed that you can do > these things. > > To protect your rights, we need to make restrictions that forbid > distributors to deny you these rights or to ask you to surrender these > rights. These restrictions translate to certain responsibilities for > you if you distribute copies of the library or if you modify it. > > For example, if you distribute copies of the library, whether gratis > or for a fee, you must give the recipients all the rights that we gave > you. You must make sure that they, too, receive or can get the source > code. If you link other code with the library, you must provide > complete object files to the recipients, so that they can relink them > with the library after making changes to the library and recompiling > it. And you must show them these terms so they know their rights. > > We protect your rights with a two-step method: (1) we copyright the > library, and (2) we offer you this license, which gives you legal > permission to copy, distribute and/or modify the library. > > To protect each distributor, we want to make it very clear that > there is no warranty for the free library. Also, if the library is > modified by someone else and passed on, the recipients should know > that what they have is not the original version, so that the original > author's reputation will not be affected by problems that might be > introduced by others. > > Finally, software patents pose a constant threat to the existence of > any free program. We wish to make sure that a company cannot > effectively restrict the users of a free program by obtaining a > restrictive license from a patent holder. Therefore, we insist that > any patent license obtained for a version of the library must be > consistent with the full freedom of use specified in this license. > > Most GNU software, including some libraries, is covered by the > ordinary GNU General Public License. This license, the GNU Lesser > General Public License, applies to certain designated libraries, and > is quite different from the ordinary General Public License. We use > this license for certain libraries in order to permit linking those > libraries into non-free programs. > > When a program is linked with a library, whether statically or using > a shared library, the combination of the two is legally speaking a > combined work, a derivative of the original library. The ordinary > General Public License therefore permits such linking only if the > entire combination fits its criteria of freedom. The Lesser General > Public License permits more lax criteria for linking other code with > the library. > > We call this license the "Lesser" General Public License because it > does Less to protect the user's freedom than the ordinary General > Public License. It also provides other free software developers Less > of an advantage over competing non-free programs. These disadvantages > are the reason we use the ordinary General Public License for many > libraries. However, the Lesser license provides advantages in certain > special circumstances. > > For example, on rare occasions, there may be a special need to > encourage the widest possible use of a certain library, so that it becomes > a de-facto standard. To achieve this, non-free programs must be > allowed to use the library. A more frequent case is that a free > library does the same job as widely used non-free libraries. In this > case, there is little to gain by limiting the free library to free > software only, so we use the Lesser General Public License. > > In other cases, permission to use a particular library in non-free > programs enables a greater number of people to use a large body of > free software. For example, permission to use the GNU C Library in > non-free programs enables many more people to use the whole GNU > operating system, as well as its variant, the GNU/Linux operating > system. > > Although the Lesser General Public License is Less protective of the > users' freedom, it does ensure that the user of a program that is > linked with the Library has the freedom and the wherewithal to run > that program using a modified version of the Library. > > The precise terms and conditions for copying, distribution and > modification follow. Pay close attention to the difference between a > "work based on the library" and a "work that uses the library". The > former contains code derived from the library, whereas the latter must > be combined with the library in order to run. > > GNU LESSER GENERAL PUBLIC LICENSE > TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION > > 0. This License Agreement applies to any software library or other > program which contains a notice placed by the copyright holder or > other authorized party saying it may be distributed under the terms of > this Lesser General Public License (also called "this License"). > Each licensee is addressed as "you". > > A "library" means a collection of software functions and/or data > prepared so as to be conveniently linked with application programs > (which use some of those functions and data) to form executables. > > The "Library", below, refers to any such software library or work > which has been distributed under these terms. A "work based on the > Library" means either the Library or any derivative work under > copyright law: that is to say, a work containing the Library or a > portion of it, either verbatim or with modifications and/or translated > straightforwardly into another language. (Hereinafter, translation is > included without limitation in the term "modification".) > > "Source code" for a work means the preferred form of the work for > making modifications to it. For a library, complete source code means > all the source code for all modules it contains, plus any associated > interface definition files, plus the scripts used to control compilation > and installation of the library. > > Activities other than copying, distribution and modification are not > covered by this License; they are outside its scope. The act of > running a program using the Library is not restricted, and output from > such a program is covered only if its contents constitute a work based > on the Library (independent of the use of the Library in a tool for > writing it). Whether that is true depends on what the Library does > and what the program that uses the Library does. > > 1. You may copy and distribute verbatim copies of the Library's > complete source code as you receive it, in any medium, provided that > you conspicuously and appropriately publish on each copy an > appropriate copyright notice and disclaimer of warranty; keep intact > all the notices that refer to this License and to the absence of any > warranty; and distribute a copy of this License along with the > Library. > > You may charge a fee for the physical act of transferring a copy, > and you may at your option offer warranty protection in exchange for a > fee. > > 2. You may modify your copy or copies of the Library or any portion > of it, thus forming a work based on the Library, and copy and > distribute such modifications or work under the terms of Section 1 > above, provided that you also meet all of these conditions: > > a) The modified work must itself be a software library. > > b) You must cause the files modified to carry prominent notices > stating that you changed the files and the date of any change. > > c) You must cause the whole of the work to be licensed at no > charge to all third parties under the terms of this License. > > d) If a facility in the modified Library refers to a function or a > table of data to be supplied by an application program that uses > the facility, other than as an argument passed when the facility > is invoked, then you must make a good faith effort to ensure that, > in the event an application does not supply such function or > table, the facility still operates, and performs whatever part of > its purpose remains meaningful. > > (For example, a function in a library to compute square roots has > a purpose that is entirely well-defined independent of the > application. Therefore, Subsection 2d requires that any > application-supplied function or table used by this function must > be optional: if the application does not supply it, the square > root function must still compute square roots.) > > These requirements apply to the modified work as a whole. If > identifiable sections of that work are not derived from the Library, > and can be reasonably considered independent and separate works in > themselves, then this License, and its terms, do not apply to those > sections when you distribute them as separate works. But when you > distribute the same sections as part of a whole which is a work based > on the Library, the distribution of the whole must be on the terms of > this License, whose permissions for other licensees extend to the > entire whole, and thus to each and every part regardless of who wrote > it. > > Thus, it is not the intent of this section to claim rights or contest > your rights to work written entirely by you; rather, the intent is to > exercise the right to control the distribution of derivative or > collective works based on the Library. > > In addition, mere aggregation of another work not based on the Library > with the Library (or with a work based on the Library) on a volume of > a storage or distribution medium does not bring the other work under > the scope of this License. > > 3. You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. To do > this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version 2, > instead of to this License. (If a newer version than version 2 of the > ordinary GNU General Public License has appeared, then you can specify > that version instead if you wish.) Do not make any other change in > these notices. > > Once this change is made in a given copy, it is irreversible for > that copy, so the ordinary GNU General Public License applies to all > subsequent copies and derivative works made from that copy. > > This option is useful when you wish to copy part of the code of > the Library into a program that is not a library. > > 4. You may copy and distribute the Library (or a portion or > derivative of it, under Section 2) in object code or executable form > under the terms of Sections 1 and 2 above provided that you accompany > it with the complete corresponding machine-readable source code, which > must be distributed under the terms of Sections 1 and 2 above on a > medium customarily used for software interchange. > > If distribution of object code is made by offering access to copy > from a designated place, then offering equivalent access to copy the > source code from the same place satisfies the requirement to > distribute the source code, even though third parties are not > compelled to copy the source along with the object code. > > 5. A program that contains no derivative of any portion of the > Library, but is designed to work with the Library by being compiled or > linked with it, is called a "work that uses the Library". Such a > work, in isolation, is not a derivative work of the Library, and > therefore falls outside the scope of this License. > > However, linking a "work that uses the Library" with the Library > creates an executable that is a derivative of the Library (because it > contains portions of the Library), rather than a "work that uses the > library". The executable is therefore covered by this License. > Section 6 states terms for distribution of such executables. > > When a "work that uses the Library" uses material from a header file > that is part of the Library, the object code for the work may be a > derivative work of the Library even though the source code is not. > Whether this is true is especially significant if the work can be > linked without the Library, or if the work is itself a library. The > threshold for this to be true is not precisely defined by law. > > If such an object file uses only numerical parameters, data > structure layouts and accessors, and small macros and small inline > functions (ten lines or less in length), then the use of the object > file is unrestricted, regardless of whether it is legally a derivative > work. (Executables containing this object code plus portions of the > Library will still fall under Section 6.) > > Otherwise, if the work is a derivative of the Library, you may > distribute the object code for the work under the terms of Section 6. > Any executables containing that work also fall under Section 6, > whether or not they are linked directly with the Library itself. > > 6. As an exception to the Sections above, you may also combine or > link a "work that uses the Library" with the Library to produce a > work containing portions of the Library, and distribute that work > under terms of your choice, provided that the terms permit > modification of the work for the customer's own use and reverse > engineering for debugging such modifications. > > You must give prominent notice with each copy of the work that the > Library is used in it and that the Library and its use are covered by > this License. You must supply a copy of this License. If the work > during execution displays copyright notices, you must include the > copyright notice for the Library among them, as well as a reference > directing the user to the copy of this License. Also, you must do one > of these things: > > a) Accompany the work with the complete corresponding > machine-readable source code for the Library including whatever > changes were used in the work (which must be distributed under > Sections 1 and 2 above); and, if the work is an executable linked > with the Library, with the complete machine-readable "work that > uses the Library", as object code and/or source code, so that the > user can modify the Library and then relink to produce a modified > executable containing the modified Library. (It is understood > that the user who changes the contents of definitions files in the > Library will not necessarily be able to recompile the application > to use the modified definitions.) > > b) Use a suitable shared library mechanism for linking with the > Library. A suitable mechanism is one that (1) uses at run time a > copy of the library already present on the user's computer system, > rather than copying library functions into the executable, and (2) > will operate properly with a modified version of the library, if > the user installs one, as long as the modified version is > interface-compatible with the version that the work was made with. > > c) Accompany the work with a written offer, valid for at > least three years, to give the same user the materials > specified in Subsection 6a, above, for a charge no more > than the cost of performing this distribution. > > d) If distribution of the work is made by offering access to copy > from a designated place, offer equivalent access to copy the above > specified materials from the same place. > > e) Verify that the user has already received a copy of these > materials or that you have already sent this user a copy. > > For an executable, the required form of the "work that uses the > Library" must include any data and utility programs needed for > reproducing the executable from it. However, as a special exception, > the materials to be distributed need not include anything that is > normally distributed (in either source or binary form) with the major > components (compiler, kernel, and so on) of the operating system on > which the executable runs, unless that component itself accompanies > the executable. > > It may happen that this requirement contradicts the license > restrictions of other proprietary libraries that do not normally > accompany the operating system. Such a contradiction means you cannot > use both them and the Library together in an executable that you > distribute. > > 7. You may place library facilities that are a work based on the > Library side-by-side in a single library together with other library > facilities not covered by this License, and distribute such a combined > library, provided that the separate distribution of the work based on > the Library and of the other library facilities is otherwise > permitted, and provided that you do these two things: > > a) Accompany the combined library with a copy of the same work > based on the Library, uncombined with any other library > facilities. This must be distributed under the terms of the > Sections above. > > b) Give prominent notice with the combined library of the fact > that part of it is a work based on the Library, and explaining > where to find the accompanying uncombined form of the same work. > > 8. You may not copy, modify, sublicense, link with, or distribute > the Library except as expressly provided under this License. Any > attempt otherwise to copy, modify, sublicense, link with, or > distribute the Library is void, and will automatically terminate your > rights under this License. However, parties who have received copies, > or rights, from you under this License will not have their licenses > terminated so long as such parties remain in full compliance. > > 9. You are not required to accept this License, since you have not > signed it. However, nothing else grants you permission to modify or > distribute the Library or its derivative works. These actions are > prohibited by law if you do not accept this License. Therefore, by > modifying or distributing the Library (or any work based on the > Library), you indicate your acceptance of this License to do so, and > all its terms and conditions for copying, distributing or modifying > the Library or works based on it. > > 10. Each time you redistribute the Library (or any work based on the > Library), the recipient automatically receives a license from the > original licensor to copy, distribute, link with or modify the Library > subject to these terms and conditions. You may not impose any further > restrictions on the recipients' exercise of the rights granted herein. > You are not responsible for enforcing compliance by third parties with > this License. > > 11. If, as a consequence of a court judgment or allegation of patent > infringement or for any other reason (not limited to patent issues), > conditions are imposed on you (whether by court order, agreement or > otherwise) that contradict the conditions of this License, they do not > excuse you from the conditions of this License. If you cannot > distribute so as to satisfy simultaneously your obligations under this > License and any other pertinent obligations, then as a consequence you > may not distribute the Library at all. For example, if a patent > license would not permit royalty-free redistribution of the Library by > all those who receive copies directly or indirectly through you, then > the only way you could satisfy both it and this License would be to > refrain entirely from distribution of the Library. > > If any portion of this section is held invalid or unenforceable under any > particular circumstance, the balance of the section is intended to apply, > and the section as a whole is intended to apply in other circumstances. > > It is not the purpose of this section to induce you to infringe any > patents or other property right claims or to contest validity of any > such claims; this section has the sole purpose of protecting the > integrity of the free software distribution system which is > implemented by public license practices. Many people have made > generous contributions to the wide range of software distributed > through that system in reliance on consistent application of that > system; it is up to the author/donor to decide if he or she is willing > to distribute software through any other system and a licensee cannot > impose that choice. > > This section is intended to make thoroughly clear what is believed to > be a consequence of the rest of this License. > > 12. If the distribution and/or use of the Library is restricted in > certain countries either by patents or by copyrighted interfaces, the > original copyright holder who places the Library under this License may add > an explicit geographical distribution limitation excluding those countries, > so that distribution is permitted only in or among countries not thus > excluded. In such case, this License incorporates the limitation as if > written in the body of this License. > > 13. The Free Software Foundation may publish revised and/or new > versions of the Lesser General Public License from time to time. > Such new versions will be similar in spirit to the present version, > but may differ in detail to address new problems or concerns. > > Each version is given a distinguishing version number. If the Library > specifies a version number of this License which applies to it and > "any later version", you have the option of following the terms and > conditions either of that version or of any later version published by > the Free Software Foundation. If the Library does not specify a > license version number, you may choose any version ever published by > the Free Software Foundation. > > 14. If you wish to incorporate parts of the Library into other free > programs whose distribution conditions are incompatible with these, > write to the author to ask for permission. For software which is > copyrighted by the Free Software Foundation, write to the Free > Software Foundation; we sometimes make exceptions for this. Our > decision will be guided by the two goals of preserving the free status > of all derivatives of our free software and of promoting the sharing > and reuse of software generally. > > NO WARRANTY > > 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO > WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. > EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR > OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY > KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE > IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE > LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME > THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. > > 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN > WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY > AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU > FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR > CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE > LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING > RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A > FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF > SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH > DAMAGES. > > END OF TERMS AND CONDITIONS > > How to Apply These Terms to Your New Libraries > > If you develop a new library, and you want it to be of the greatest > possible use to the public, we recommend making it free software that > everyone can redistribute and change. You can do so by permitting > redistribution under these terms (or, alternatively, under the terms of the > ordinary General Public License). > > To apply these terms, attach the following notices to the library. It is > safest to attach them to the start of each source file to most effectively > convey the exclusion of warranty; and each file should have at least the > "copyright" line and a pointer to where the full notice is found. > > > Copyright (C) > > This library is free software; you can redistribute it and/or > modify it under the terms of the GNU Lesser General Public > License as published by the Free Software Foundation; either > version 2.1 of the License, or (at your option) any later version. > > This library is distributed in the hope that it will be useful, > but WITHOUT ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > Lesser General Public License for more details. > > You should have received a copy of the GNU Lesser General Public > License along with this library; if not, write to the Free Software > Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > > Also add information on how to contact you by electronic and paper mail. > > You should also get your employer (if you work as a programmer) or your > school, if any, to sign a "copyright disclaimer" for the library, if > necessary. Here is a sample; alter the names: > > Yoyodyne, Inc., hereby disclaims all copyright interest in the > library `Frob' (a library for tweaking knobs) written by James Random Hacker. > > , 1 April 1990 > Ty Coon, President of Vice > > That's all there is to it! > ------------------------ end of proposed license ------------------ > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From gjhanna at gmail.com Sun Mar 11 14:21:17 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Mon, 12 Mar 2007 09:21:17 +1300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hi Pavel, We are using RXTX under VMWare server in production, quite satisfactorily. We're using Red Hat Enterprise Server 4, and ... Whatever the "enterprise" VMWare product is. Regards, Greg H > Subject: [Rxtx] RXTX under VMWare server > To: rxtx at qbang.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. [ ... snip ... ] -- Pavel Parkhomenko -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070311/4cebb6f9/attachment-0001.html From gergg at cox.net Sun Mar 11 23:39:19 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 12 Mar 2007 00:39:19 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: <45F4E787.6050502@cox.net> Trent Jarvi wrote: > I can start going through the method interfaces later this week and giving > feedback. I would suggest that the JSR should not be too generic in > nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel > drivers that intend to look like EIA232 ports at the kernel driver level. > > some ideas: > > EIA232PortInterface > TermiosInterface > SerialPortInterface > > Something that differentiates this from thing like USB, I2C, ... which > should not have to deal with legacy serial claiming to be the comm api. I'm going to throw out a suggestion, which I am mostly serious about. What would happen if we took the appropriate bits of the J2ME connector API, and just used that as the new COMM API so that finally JSE and JME had a common foundation for these kinds of things? Gregg Wonderly From ra85551 at gmail.com Mon Mar 12 09:08:37 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Mon, 12 Mar 2007 18:08:37 +0300 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Should any application use the modem, HyperTerminal won't be able to talk to the modem. But it actually can send and receive AT comands, while my application cannot :-( > Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Thansk for the reference. I examined that example and found that there's no significant differences between my read/write implementation and that one, except that SimpleSnuV1 listens for serialEvent's, but not for sake of data retrieval, just for printing them out - I don't know why ;-) > Note that modems could care less what OS is on top. If you are trying to > match new lines to the OS and sending it to the mode for AT commands, > thats probably a mistake. I do send strings to serial port, not to OS, and do try to get answers back. If it is the mistake, what's the right way? > Also it would not hurt to print out the > individual bytes that you are sending to make sure they did not get > mangled along the path. Yeah, I am printing these bytes before doing write, but it means that I only see what I intend to write. How can I ensure that these bytes have gone out of the box and reached my modem? BTW, I found that my send/receive method is complex enough, so I've rewritten it. Please, see the following code and point any mistakes, because I don't know where can they remain yet. private static final int LARGE_TIMEOUT = 15000; private static final int SMALL_TIMEOUT = 500; ... private String sendATCommand(String command, String waitFor, boolean isRegex, boolean isAddCRLF) throws BeaconConnectException { byte[] buffer = new byte[512]; int offset; String result = ""; try { if (waitFor != null) { serialPort.enableReceiveTimeout(LARGE_TIMEOUT); } else { serialPort.enableReceiveTimeout(SMALL_TIMEOUT); } if (command != null) { OutputStream serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } offset = 0; InputStream serialInput = serialPort.getInputStream(); while (serialInput.available() != -1) { int bytesRead = serialInput.read(buffer, offset, buffer.length - offset); if (bytesRead == 0) { break; } offset += bytesRead; result = new String(buffer, 0, offset).trim(); if (waitFor != null) { System.out.println(result); if (isRegex && result.matches(waitFor) || result.contains(waitFor)) { break; } } } } catch (UnsupportedCommOperationException e) { throw new MyException("unsupported operation"); } catch (IOException e) { throw new MytException("serial I/O error"); } return result; } -- Pavel Parkhomenko From clayno at hotpop.com Thu Mar 15 02:47:34 2007 From: clayno at hotpop.com (Christopher Layno) Date: Thu, 15 Mar 2007 16:47:34 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi, we're using the latest release of rxtx (2.1-7r2) for our system that has two applications using the library. one application sends requests to the modem while the other simply checks the modem status. we deployed our system on a pentium machine with red hat linux 9.0 installed. now the problem arises when these two applications try to access the same modem at the same time. one of them will eventually have to throw the PortInUseException as shown below: 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException gnu.io.PortInUseException: root PID = 743 Program = java root PID = 743 Program = java root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) this was expected. what we didn't expect though was that if we repeat the scenario 5 times, always 5 times, the application would also throw a VM error: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4473CD21 Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so Current Java thread: at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) - locked <0x44cfd4c8> (a gnu.io.CommPortIdentifier) at ************ at ************ - locked <0x4476a468> (a **********) at ************ at ************ at ************ at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java :261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages( TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run( TCPTransport.java:701) at java.lang.Thread.run(Thread.java:534) note: i replaced some sensitive data with asterisks our team has looked everywhere on the internet, including your mail archives, for a solution to this problem but to no avail. i really hope you could help us out on this one. thanks in advance! best regards, chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070315/1936460a/attachment-0001.html From tjarvi at qbang.org Fri Mar 16 04:30:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 04:30:25 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: On Thu, 15 Mar 2007, Christopher Layno wrote: > hi, > > we're using the latest release of rxtx (2.1-7r2) for our system that has two > applications using the library. one application sends requests to the modem > while the other simply checks the modem status. we deployed our system on a > pentium machine with red hat linux 9.0 installed. > > now the problem arises when these two applications try to access the same > modem at the same time. one of them will eventually have to throw the > PortInUseException as shown below: > > 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException > gnu.io.PortInUseException: root PID = 743 Program = java root PID = > 743 Program = java root PID = 743 Program = ??? root PID = 743 Program > = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root > PID = 743 Program = ??? root PID = 743 Program = ??? > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > > this was expected. what we didn't expect though was that if we repeat the > scenario 5 times, always 5 times, the application would also throw a VM > error: > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x4473CD21 > Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 > Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so > > Current Java thread: > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) Hi Chris The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. The code is originally by Werner Almesberger. He gave us permission to use it in rxtx. You might look at what has changed since 1998 in his fuser application. Or you can just do like other OSs and do the following in fuserImp.c JNIEXPORT jstring JNICALL Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv *env, jobject obj, jstring arg) { return (*env)->NewStringUTF(env, "Unknown Application"); } It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. -- Trent Jarvi tjarvi at qang.org From Adrien.TOS at ingenico.com Fri Mar 16 05:11:12 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Fri, 16 Mar 2007 12:11:12 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903CBC312@frsnprexc1.usr.ingenico.loc> Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070316/972ab214/attachment-0001.html From joachim at buechse.de Fri Mar 16 05:13:24 2007 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 16 Mar 2007 12:13:24 +0100 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. From tjarvi at qbang.org Fri Mar 16 16:36:29 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 16:36:29 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Fri Mar 16 16:02:23 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 16 Mar 2007 18:02:23 -0400 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Not all platforms are Unix based. Also mixing native library usage and command-line calls is not an elegant solution, IMHO. One or the other, but not both. Andre On 16-Mar-07, at 07:13 , Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is > trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We >> only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From clayno at hotpop.com Sun Mar 18 22:17:28 2007 From: clayno at hotpop.com (Christopher Layno) Date: Mon, 19 Mar 2007 12:17:28 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi everyone, thank you so much for your replies. they were really helpful. anyway, before i sent the email, my team was already implementing a temporary solution by using joachim's suggestion. we invoked a lsof command from our java code although i share the same concern with trent and andre-john about portability issues. that's why i said it's just temporary. my superiors have yet to approve our bug fix. so my question now is this: is recompiling the rxtx source code the only way to solve this problem? because if it's the only solution, then i think my superiors would rather have a new release from the rxtx community itself that fixes this bug(?) rather than have my team recompile the source code. best regards, chris Trent Jarvi wrote: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. ... It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070318/237463b2/attachment-0001.html From tjarvi at qbang.org Mon Mar 19 16:20:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Mar 2007 16:20:52 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: Hi Chris I can compile a new version after the 21st if you do not feel comfortable doing so. Please send me an email reminder off-line then. On Mon, 19 Mar 2007, Christopher Layno wrote: > hi everyone, > > thank you so much for your replies. they were really helpful. > > anyway, before i sent the email, my team was already implementing a > temporary solution by using joachim's suggestion. > we invoked a lsof command from our java code although i share the same > concern with trent and andre-john about > portability issues. that's why i said it's just temporary. my superiors have > yet to approve our bug fix. > > so my question now is this: is recompiling the rxtx source code the only way > to solve this problem? because if it's the only > solution, then i think my superiors would rather have a new release from the > rxtx community itself that fixes this bug(?) > rather than have my team recompile the source code. > > best regards, > > chris > > Trent Jarvi wrote: > > Hi Joachim > > It would be nice to have that functionality but calling the program > introduces too many issues imho. Explaining to someone why rxtx invoked a > rogue lsof does not sound very interesting. > > On Fri, 16 Mar 2007, Joachim Buechse wrote: > > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: > > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. > > _______________________________________________ > Rxtx mailing list > Rxtx 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 Eric.Arseneau at sun.com Tue Mar 20 11:47:33 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Tue, 20 Mar 2007 10:47:33 -0700 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 Message-ID: <46001E35.9040608@sun.com> Anyone have any experience with RXTX working with JDK 6 on other platforms ? From mm at UDel.Edu Tue Mar 20 12:18:29 2007 From: mm at UDel.Edu (Mike Markowski) Date: Tue, 20 Mar 2007 14:18:29 -0400 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 In-Reply-To: <46001E35.9040608@sun.com> References: <46001E35.9040608@sun.com> Message-ID: <46002575.4000306@udel.edu> Eric Arseneau wrote: > Anyone have any experience with RXTX working with JDK 6 on other platforms ? I'm using 32 bit intel, gentoo linux, jdk6 with no problems. My applications only use a serial port, though, nothing on the parallel port. Mike From falko.guderian at gmx.de Wed Mar 21 08:17:35 2007 From: falko.guderian at gmx.de (Falko Guderian) Date: Wed, 21 Mar 2007 15:17:35 +0100 Subject: [Rxtx] RXTX binaries for SH4 Message-ID: <46013E7F.40102@gmx.de> Dear developers, I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no possiblities to compile the source code. Better, I'm not able to do this at the moment. Can you provide me with rxtxSerial.dll (SH4) in the rxtx-2.1-8-testing version? (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) The reason for the testing version is I need custom baud rates. Thanks for help. Kind regards, Falko Guderian From tjarvi at qbang.org Wed Mar 21 21:38:37 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Mar 2007 21:38:37 -0600 (MDT) Subject: [Rxtx] RXTX binaries for SH4 In-Reply-To: <46013E7F.40102@gmx.de> References: <46013E7F.40102@gmx.de> Message-ID: On Wed, 21 Mar 2007, Falko Guderian wrote: > Dear developers, > > I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no > possiblities to compile the source code. Better, I'm not able to do this > at the moment. Can you provide me with rxtxSerial.dll (SH4) in the > rxtx-2.1-8-testing version? > (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) > > The reason for the testing version is I need custom baud rates. > > Thanks for help. > Hi Falko WinCE binary format is not supported by gcc. That makes compiling limited to those familiar with the WinCE tools. I hope someone is able to provide them for you but it is not likely. WinCE has been compiled by others in the past but rxtx.org builds have never included WinCE. There is some information with the source concerning WinCE builds if you decide to do it. We can share your results too if you like. The source in the WinCE has never been updated for the custom baud rate. That would need changes from the main source I presume. If you look at the source, you will note that Michal Hobot created a mini fork in the source to handle wince but it has not been updated for 3 years. -- Trent Jarvi tjarvi at qbang.org From Adrien.TOS at ingenico.com Thu Mar 22 07:08:55 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Thu, 22 Mar 2007 14:08:55 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Hi everybody, Do you have any comments on this issue? Thanks! AT ________________________________ De : Adrien TOS Envoy? : vendredi 16 mars 2007 12:11 ? : 'rxtx at qbang.org' Cc : Adrien TOS Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070322/2306c538/attachment-0001.html From jeremy.reeve at zen.co.uk Mon Mar 19 07:36:04 2007 From: jeremy.reeve at zen.co.uk (Jeremy S. Reeve) Date: Mon, 19 Mar 2007 13:36:04 +0000 Subject: [Rxtx] rxtx failing to compile on Fedora Core 6 Message-ID: <1174311364.21865.6.camel@d9thc> When trying to compile latest source : rxtx-2.1-7r2 I get the following when running configure: ---------------- checking os.version 2.6.18-1.2200.fc5smp WARNING: configure is having a hard time determining which directory contains the file jni_md.h. Edit Makefile and fix the variable JAVANATINC to point to the correct directory. The following options are available: /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/ /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/linux/ If there are more than one option available the first was selected. WARNING: Kernel include files do not match the current kernel configure: creating ./config.status ------------------------ which seems OK checking the resultant Makefile but when attempting to build with gmake install I get the following output : ---------------------- 34 problems (34 warnings)/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/javah -classpath .:/home/jsr/rxtxsrc/rxtx-2.1-7r2:/home/jsr/rxtxsrc/rxtx-2.1-7r2/src:/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/ext/RXTXcomm.jar -d i686-pc-linux-gnu -jni `(for i in CommDriver CommPortEnumerator CommPortIdentifier CommPort CommPortOwnershipListener Configure I2C I2CPortEvent I2CPortEventListener I2CPort LPRPort NoSuchPortException ParallelPortEvent ParallelPortEventListener ParallelPort PortInUseException Raw RawPortEvent RawPortEventListener RawPort RS485 RS485PortEvent RS485PortEventListener RS485Port RXTXCommDriver RXTXPort RXTXVersion SerialPortEvent SerialPortEventListener SerialPort UnsupportedCommOperationException UnSupportedLoggerException Zystem;do \ if grep > /dev/null native.* \( /home/jsr/rxtxsrc/rxtx-2.1-7r2/./src/$i.java; then \ echo gnu.io.$i; \ fi; \ done)` i686-pc-linux-gnu/gnu_io_CommPortIdentifier.h: No such file or directory make: *** [/home/jsr/rxtxsrc/rxtx-2.1-7r2/gnu/io/CommDriver.class] Error 1 ------------------------ Any ideas or pointers? Regards, Jeremy From tjarvi at qbang.org Sat Mar 24 08:12:54 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 Mar 2007 08:12:54 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > From Adrien.TOS at ingenico.com Sat Mar 24 11:53:22 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Sat, 24 Mar 2007 18:53:22 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> I do not have the threshold setting enabled, I have explicitely disabled it with: port_.disableReceiveThreshold(); I have also run the same tests with the threshold setting enabled, but they also fail in the same way as described below. So it seems there is a problem with timeout handling on Win32? ________________________________ From: rxtx-bounces at qbang.org on behalf of Trent Jarvi Sent: Sat 3/24/2007 3:12 PM To: RXTX Developers and Users Subject: Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 8312 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20070324/f9e39c9b/attachment-0001.bin From greg.johnson at manchester.ac.uk Sun Mar 25 13:41:36 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Sun, 25 Mar 2007 21:41:36 +0200 Subject: [Rxtx] Mac intel weirdness Message-ID: Hi folks, I'm trying to get rxtx to work on my macbook pro with a USB-serial dongle on it. I am using the 2.1-8 code from the CVS (though it seems to report itself as 2.1-7: makes it difficult to prove to oneself that the changes have 'taken'! - line 4210 in SerialImp.c, line 40 in RXTXVersion.java) I am trying the 2.1-8 because of horrible lock problems in 2.1-7. However, the serialport closure code seems to be broken - it won't close because it believes the (previously opened!) port doesn't exist. Here is what I'm trying: 0. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "false" 1. Open a port Serialport serialport = (SerialPort) commportidentifier.open ("test",100); 2. Talk to a device ... 3. Close port serialport.close(); 4. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "true" - why is this? 5. Try to reopen port Serialport serialport2 = (SerialPort) commportidentifier.open("test", 100); throws PortInUseException. I've dug around a bit in the source, and it seems the SerialPort.close () should call the CommPortIdentifier.internalClosePort() (line 67 of CommPort.java). However, I crash out with the NoSuchPortException when getPortIdentifier is called. Which seems quite weird to me, seeing as it is called on this - which was create just beforehand. Does anyone know how to fix this? Cheers, greg From knute at frazmtn.com Sat Mar 24 10:32:38 2007 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 24 Mar 2007 09:32:38 -0700 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc>, Message-ID: <4604F036.17833.135298@knute.frazmtn.com> > >The behavior of timeout depends upon the setting of the threshold. Do you >have the threshold setting? > This is the same bug I reported last fall. There was a fellow that sent me an email asking if it had been fixed. I told him I didn't think so. He got somebody to write a fix for him but I have not been able to contact him again for the actual changes. The inaccurate timeout and the failure of blocking when no timeouts are set is a serious bug in my humble opinion and renders the software unusable for my applications. I'd really like to have an alternative to the Sun comm api but there just isn't one that I know of. -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Mar 26 16:17:00 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 26 Mar 2007 16:17:00 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> Message-ID: >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. From ra85551 at gmail.com Tue Mar 27 10:18:36 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Tue, 27 Mar 2007 20:18:36 +0400 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Ultimately I found a solution. At first, that wasn't actually the VMWare + WinXP + RXTX issue, that was WinXP + RXTX issue. But on pure XP it sometimes workes, sometimes not, while under VMWare I had never seen my snippet working at all. SimpleSnuV1.java would not help me, because there is only one line I missed, and SimpleSnuV1.java also doesn't contain it! It is as follows: serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_OUT | SerialPort.FLOWCONTROL_RTSCTS_IN); Thank you for your attention. -- Pavel Parkhomenko From griff at op.pl Wed Mar 28 01:28:19 2007 From: griff at op.pl (griff@op.pl) Date: Wed, 28 Mar 2007 09:28:19 +0200 Subject: [Rxtx] No blocking read on Windows. Message-ID: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/5d07d571/attachment-0001.html -------------- next part -------------- Hi, I have problem that InputStram.read() (SerialPort)?returns -1 instead blocking and waiting for data. I found that this problem was ?known in 2005 : ? >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > >> Hi Trent >> >> Thanks for the fast response. >> Here's a Q&D test program for the blocking read on windows that just >> attempts to read one byte, and prints the resulting byte. On my system it >> returns -1, where I expect that it keeps waiting for data. >> >This isn't happening on Linux so the bug is in src/termios.c.? I'll have >something this weekend to fix that. I'm using RXTX 2.1.7r2 and the problem still is here. Im using Windows XP and java 1.5 disableReciveTimeout() and disableReciveTreshhold() dont help. ? best regards ? Piotr Zielniok From Adrien.TOS at ingenico.com Wed Mar 28 01:40:46 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Wed, 28 Mar 2007 09:40:46 +0200 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903E88880@frsnprexc1.usr.ingenico.loc> Looking at the code, it seems there is no support for infinite timeout? And maybe the count++ < 20 condition is breaking out of the loop too early? The only condition to break out of the loop should either be the timeout has expired or the number of requested bytes has been received. -----Message d'origine----- De : rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] De la part de Trent Jarvi Envoy? : mardi 27 mars 2007 00:17 ? : RXTX Developers and Users Objet : Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From j.kenneth.gentle at acm.org Wed Mar 28 06:44:15 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 28 Mar 2007 08:44:15 -0400 Subject: [Rxtx] No blocking read on Windows. In-Reply-To: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> References: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> Message-ID: <200703281844.l2SIiITW028614@qbang.org> Just another "ME TOO!" - I'm seeing this problem on Windows XP, jre for windows XP/Embedded. I cranked receiveTimeout up to Integer.MAX_INT, but it doesn't seem to wait that long At 03:28 2007-03-28, you wrote: >Hi, >I have problem that InputStram.read() (SerialPort) returns -1 >instead blocking and waiting for data. I found that this problem >was known in 2005 : > > >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > > > >> Hi Trent > >> > >> Thanks for the fast response. > >> Here's a Q&D test program for the blocking read on windows that just > >> attempts to read one byte, and prints the resulting byte. On my system it > >> returns -1, where I expect that it keeps waiting for data. > >> > > >This isn't happening on Linux so the bug is in src/termios.c. I'll have > >something this weekend to fix that. > >I'm using RXTX 2.1.7r2 and the problem still is here. >Im using Windows XP and java 1.5 >disableReciveTimeout() and disableReciveTreshhold() dont help. > >best regards > >Piotr Zielniok > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From greg.johnson at manchester.ac.uk Wed Mar 28 14:43:29 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Wed, 28 Mar 2007 22:43:29 +0200 Subject: [Rxtx] Cannot close and reopen serial port Message-ID: <377F9765-7A9D-4CE9-9176-FFB63A2594F0@manchester.ac.uk> Dear all, It appears I cannot close a port properly: SerialPort serialport = portid.open("myprog",100); // do some stuff, all works fine serialport.close(); // all seems fine but... SerialPort sp2 = portid.open("myprog",100); throws PortInUseException. And when I dig into the rxtx code, I find in CommPort.java, in close(): CommPortIdentifier cp = CommPortIdentifier.getPortIdentifier(this); (line 64 or there abouts) but this throws a NoSuchPortException which is caught but ignored (line 74ish). Can anyone suggest how this could happen: a port that was valid, opened, and used, throws a NSPE when it comes to closing it? I'm pulling my (remaining) hair out over this one! Cheers, greg PS And thanks for RXTX - it's great to have! PPS (21.-7. winxp/osx both, java 1.5) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/c28852fc/attachment-0001.html From rxtx at vrijheidslaan.net Fri Mar 30 16:52:50 2007 From: rxtx at vrijheidslaan.net (Rob) Date: Fri, 30 Mar 2007 22:52:50 -0000 Subject: [Rxtx] Cvs Question Message-ID: <61896.80.126.150.87.1175295162.squirrel@webmail.provalue.nl> Hi There, Im trying to get the latest version to work on mac osx. Problem is that i can't checkout version 2.1.8. Probably my fault but can some one please give me the alternative commands for: [user at myhost]$ export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot [user at myhost]$ cvs login Thanx, Rob From ra85551 at gmail.com Thu Mar 1 03:47:06 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Thu, 1 Mar 2007 13:47:06 +0300 Subject: [Rxtx] enableReceiveTimeout() issue Message-ID: Hello, world! I found a limitation of 16300 ms for CommPort's enableReceiveTimeout() method, while in original javax.comm docs there are no any references to that. Is that a bug or feature? I actually need longer timeouts sometimees. -- Pavel Parkhomenko From lyon at docjava.com Thu Mar 1 07:54:17 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 01 Mar 2007 09:54:17 -0500 Subject: [Rxtx] parametric singleton design pattern In-Reply-To: References: <22d55aea0702081207q5e7f6785l352d498d6f5f9fb1@mail.gmail.com> <22d55aea0702100034o3bcf42f3j1d1a6257029a67b0@mail.gmail.com> Message-ID: Hi All, I have been thinking about the use of a design pattern to cache resources that are consumed by processes. Toward that end, I have arrived at a parametric singleton design pattern, which I mentioned on this list some time ago. The idea has been published at: http://www.jot.fm/issues/issue_2007_03/column2 I can't help but think that there should be an API available for dealing with the tracking of serial port usage. Perhaps it is a kind of resource manager called the: SerialPortManager basic prototypes already exist in this vain. See, for example: http://www.ce.rit.edu/research/projects/2005_fall/rt_poolsystem/doc/PoolMon/SerialPortManager.html http://www.eventhelix.com/RealtimeMantra/PatternCatalog/serial_port_design_pattern.htm And others shown by a google search on "SerialPortManager" Cheers! - Doug From Eric.Arseneau at sun.com Thu Mar 1 10:15:03 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:15:03 -0800 Subject: [Rxtx] Any known Java 6 issues with RXTX 2.1-7r2 ? Message-ID: <45E70A17.1060206@sun.com> I just did a test on a recent build of Solaris 11 x86 and it seems that I can connect to my serial device fine when Java 5 is the default, but when Java 6 is the default, no go. Any information ? From Eric.Arseneau at sun.com Thu Mar 1 10:19:58 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:19:58 -0800 Subject: [Rxtx] Mac OS X and missing data Message-ID: <45E70B3E.7040908@sun.com> We have a device which is USB based but presents itself as a serial port to a machine. On my MacBook Pro I can get excellent throughput if I get my device to send data as quickly as possible. On the desktop side, if I do an type of disk IO to log the data I get, I end up with some missing data at some point. I hooked up a USB analyzer and did confirm that all the data is sent as expected to the desktop from the device. I found a work around for this, buffer the data in memory and only write the data out when I've received it all. However, when the same code and same device is attempted on a co-workers MacBook Pro (same hardware specs), I get errors and must slow down dramatically the device side's sending of data. Any ideas/recommendations on what I can do to get rid of this error ? From what I can tell, it seems that RXTX is not able to wake up to the interrupts coming in indicating data is ready, quickly enough, is there anything I can do ? From chinkaiw at hotmail.com Fri Mar 2 00:57:43 2007 From: chinkaiw at hotmail.com (Wang Chinkai) Date: Fri, 02 Mar 2007 07:57:43 +0000 Subject: [Rxtx] dynamic detect rs232 port Message-ID: Hi all I have a question about detecting rs232 port dynamicly. I have to aceess some port and detect rs232 port at the same time. Some usb device simulates rs232 port , and I can not know what the port name it gets until it connects,so I have to detect it dynamic,but I have to access another rs232 device at the same time. I found a problem. If I use CommPortIdentifier.getPortIdentifiers() to get new port list , and the other rs232 access function will not close port correctly. So , How can I solve it . Thanks. _________________________________________________________________ ?? 2GB ???? Windows Live Mail ????????????? http://ideas.live.com/programpage.aspx?versionid=5d21c51a-b161-4314-9b0e-4911fb2b2e6d From eu259473 at tele2.it Fri Mar 2 06:16:40 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 02 Mar 2007 14:16:40 +0100 Subject: [Rxtx] rxtx on HP tru 64 unix Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070302/706c7a70/attachment-0002.html From tjarvi at qbang.org Fri Mar 2 08:39:33 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 08:39:33 -0700 (MST) Subject: [Rxtx] rxtx on HP tru 64 unix In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, "Giuseppe Marchese" wrote: > Hi > > I try to install rxtx on hp tru 64 but make fails, > There are somebody that do the same and work. > > > Sorry for may english! > > Hi Giuseppe Could you provide a log of the failure? script ./configure make # use gnu make exit The information will be in the typescript created. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 2 19:56:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 19:56:52 -0700 (MST) Subject: [Rxtx] dynamic detect rs232 port In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, Wang Chinkai wrote: > Hi all > > I have a question about detecting rs232 port dynamicly. > > I have to aceess some port and detect rs232 port at the same time. > Some usb device simulates rs232 port , and I can not know > what the port name it gets until it connects,so I have to detect it > dynamic,but I have to access > another rs232 device at the same time. > > I found a problem. Hi Wang This is a known problem. The code is braindead there. In fact there needs to be events even in a rudamentary way when you add a usb dongle. I'm burried in tasks not far from rxtx but not in rxtx. I can't get to the problem but we would accept patches if you dig into it. [I'm getting to the license question earlier too; I don't have another 10%] -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Fri Mar 2 23:19:01 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 01:19:01 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Hi, Under ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable USB -> serial converter(using virtual com port drivers), with using example code pretty much straight out of http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port opens fine, enumerations all work, etc. My application calls for a large amount of data to be transferred in a short amount of time at 2,000,000 baud. My hardware sends approximately 15,232 bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL converter work fine, and the application works using C++. In C++, I do a hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); to open the port, and a boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); to read the port. The variable buffer fills with the 15238 bytes, and returns. If I do a resultz = is.read(cbuf,0,15238); in java with RXTX where is = new BufferedReader(new InputStreamReader(port.getInputStream())); and where resultz is an int, and cbuf is a char [] cbuf, resultz gets EXACTLY 3968 bytes the first time called. If I call it multiple times, I get roughly 11k total(less than what is sent), never more than the 3968 bytes per is.read() call. My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 bytes. I've played with inputbuffersize, receive threshold, receivetimeout, and so on. The FTDI virtual com port drivers that I'm using are rock solid, and have had zero problems with them using a variety of applications, some of my own, some professionally written, etc. No flow control is used anyplace, no RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. No exceptions are being thrown. What am I doing wrong, and what I can adjust to receive the full 15k bytes in one single read? Thanks! Keith From Eric.Arseneau at sun.com Fri Mar 2 23:32:07 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Fri, 02 Mar 2007 22:32:07 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <45E91667.20501@sun.com> This is the same type of thing that is happening to me on Mac OS X and does not seem to behave the same on different machines. I posted a day or two ago on this with subject "Mac OS X and missing data". Would love to hear if there is a solution to this :) From tjarvi at qbang.org Sat Mar 3 10:54:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 10:54:17 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > Hi, > > Under > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable > USB -> serial converter(using virtual com port drivers), with using example > code pretty much straight out of > http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port > opens fine, enumerations all work, etc. > > My application calls for a large amount of data to be transferred in a short > amount of time at 2,000,000 baud. My hardware sends approximately 15,232 > bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL > converter work fine, and the application works using C++. > > In C++, I do a > > hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, > OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); > > to open the port, and a > > boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); > > to read the port. > > The variable buffer fills with the 15238 bytes, and returns. > > If I do a > > resultz = is.read(cbuf,0,15238); in java with RXTX > > where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > > and where resultz is an int, and cbuf is a char [] cbuf, resultz gets > EXACTLY 3968 bytes the first time called. If I call it multiple times, I get > roughly 11k total(less than what is sent), never more than the 3968 bytes > per is.read() call. > > My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 > bytes. > > I've played with inputbuffersize, receive threshold, receivetimeout, and so > on. The FTDI virtual com port drivers that I'm using are rock solid, and > have had zero problems with them using a variety of applications, some of my > own, some professionally written, etc. No flow control is used anyplace, no > RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. > > No exceptions are being thrown. > > What am I doing wrong, and what I can adjust to receive the full 15k bytes > in one single read? > > Thanks! > Hi Keith I would expect a 20 meg application is going to have different behavior with the OS than a smaller application with respect to the kernel memory managment, schedualing, ... Something subtle could be causing problems. With respect to the recieve timeout and threshold, if you set the timeout to zero and the threshold to the size of data you expect, read should not return until it get that data. You may try with a stand alone application that tests just that with the C/C++ API. If the read is returning with less data when tested for short reads, you have found a bug in the device driver more than likely. The USB dongle vendor would probably be interested in knowing about this. As mentioned, these devices are getting very good; almost bug free. I suspect you found a bug though if you did use the threshold and timeout properly. The missing data is typical when not using flow control. When the OS buffering fills, the hardware will start dropping bytes. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:38:52 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:38:52 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> update: I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now instead of 3968. This makes sense. 128 bytes of overhead + 3968 bytes of data = 4096 transfer size 32 bytes of overhead + 992 bytes of data = 1024 transfer size. 1/4 the data = 1/4 the overhead. I rearranged my reading like so: resultz = is.read(cbuf,0,3968); resultz = is.read(cbuf,3968,3968); resultz = is.read(cbuf,7936,3968); while (!(is.ready())); // wait for ready resultz = is.read(cbuf,11904,3334); and this grabs 15,238 bytes total. BUT, I still have the quandry of the screwed up multi-bytes. I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. Approx 8% of the data. The bad bytes always seem to take the flavor of 0x2018, 0x2019, x2022, x2030, x201d. Are these maybe errors and I don't know what they enumerate to? I still can't believe some other layer isn't handling putting those bytes together all in one stream for me. Thanks Keith ----- Original Message ----- From: "Keith" To: "Bob Jacobsen" ; "RXTX Developers and Users" Sent: Saturday, March 03, 2007 11:26 AM Subject: Re: [Rxtx] is.read() only returning 3968 bytes > Bob, > > > Interesting numerical coincidence is that (max USB transfer) - (what > > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > > needed to transfer that much data. > > I was thinking along the same lines. I don't know USB well, but I do know > that those numbers were close enough to warrant investigating the > relationship between them. > > > I think what you're seeing is the internal buffering of the USB data > > stream. You'll need some form of higher-level buffering to smooth > > that out. > > Shouldn't the InputStreamReader() and BufferedReader() provide this type of > buffering? Isn't that the idea behind those? > > > All hypotheses need to be tested. In this case, a test would be to > > check for missing data. If this idea is right, you'll get _all_ the > > data, but you won't be missing characters. > > I did start looking at the data. -- I'm getting weird results. > > I tried this: > > loopzz = 0; > > for (looptwo = 0; looptwo < 100000; looptwo++) { > while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > > }} > > So I'm reading one character at a time. The good news is that loopzz is > exactly 15238 at the end of the routine, which is perfectly correct. I > picked looptwo value out of thin air. > > The weird results come in terms of the values, the data isn't correct at > least in one case. Look here: > > 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > > This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). > But the 0x89 was replaced by 0x2030. Why the heck would the returned value > be 0x2030?? Why is the returned byte completely out of range? Why the > multibyte return? > > From InputStream in the API: > > read > public abstract int read() > throws IOExceptionReads the next byte of data from the > input stream. The value byte is returned as an int in the range 0 to 255. If > no byte is available because the end of the stream has been reached, the > value -1 is returned. This method blocks until input data is available, the > end of the stream is detected, or an exception is thrown. > Value should be 0-255. > > > In my application time is really critical, reading 1 byte at a time is > probably not going to work. > > Thanks Eric & Bob for looking at this. > > Keith > From tjarvi at qbang.org Sat Mar 3 12:52:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 12:52:27 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > update: > > I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now > instead of 3968. > > This makes sense. > > 128 bytes of overhead + 3968 bytes of data = 4096 transfer size > 32 bytes of overhead + 992 bytes of data = 1024 transfer size. > > 1/4 the data = 1/4 the overhead. > > I rearranged my reading like so: > > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. > Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? > > I still can't believe some other layer isn't handling putting those bytes > together all in one stream for me. > The layer for this in Serial land is flow control. Software and hardware flow control prevent the overruns you observe. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:54:41 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:54:41 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <001a01c75dcd$c8802a70$6600a8c0@jbh757ktruws7g> Trent, Thanks for taking the time to reply. > I would expect a 20 meg application is going to have different behavior > with the OS than a smaller application with respect to the kernel memory > managment, schedualing, ... Something subtle could be causing problems. Well, at least I know the VCP drivers, the OS, etc can handle 2mbps reliably. Without hiccuping or dropping bytes. The C++ code works reliably without flow control. > The missing data is typical when not using flow control. When the OS > buffering fills, the hardware will start dropping bytes. I'm actually not getting MISSING data, I'm getting CORRUPTED data. If you look at my most recent post, I'm getting these bad bytes in place of the correct values: 0x2018, 0x2019, x2022, x2030, x201d. Why would is.read() return values not in the range of 0-255 ? Thanks. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 08:59:14 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 07:59:14 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: At 1:19 AM -0500 3/3/07, Keith wrote: >If I do a > >resultz = is.read(cbuf,0,15238); in java with RXTX > >where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > >and where resultz is an int, and cbuf is a char [] cbuf, resultz gets >EXACTLY 3968 bytes the first time called. If I call it multiple times, I get >roughly 11k total(less than what is sent), never more than the 3968 bytes >per is.read() call. > >My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 >bytes. Interesting numerical coincidence is that (max USB transfer) - (what you get) = 4096-3968 = 128 bytes is (almost) the size of the headers needed to transfer that much data. I think what you're seeing is the internal buffering of the USB data stream. You'll need some form of higher-level buffering to smooth that out. All hypotheses need to be tested. In this case, a test would be to check for missing data. If this idea is right, you'll get _all_ the data, but you won't be missing characters. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 09:26:14 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 11:26:14 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Bob, > Interesting numerical coincidence is that (max USB transfer) - (what > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > needed to transfer that much data. I was thinking along the same lines. I don't know USB well, but I do know that those numbers were close enough to warrant investigating the relationship between them. > I think what you're seeing is the internal buffering of the USB data > stream. You'll need some form of higher-level buffering to smooth > that out. Shouldn't the InputStreamReader() and BufferedReader() provide this type of buffering? Isn't that the idea behind those? > All hypotheses need to be tested. In this case, a test would be to > check for missing data. If this idea is right, you'll get _all_ the > data, but you won't be missing characters. I did start looking at the data. -- I'm getting weird results. I tried this: loopzz = 0; for (looptwo = 0; looptwo < 100000; looptwo++) { while (is.ready()) { cbuf[loopzz] = (char) is.read(); loopzz++; }} So I'm reading one character at a time. The good news is that loopzz is exactly 15238 at the end of the routine, which is perfectly correct. I picked looptwo value out of thin air. The weird results come in terms of the values, the data isn't correct at least in one case. Look here: 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). But the 0x89 was replaced by 0x2030. Why the heck would the returned value be 0x2030?? Why is the returned byte completely out of range? Why the multibyte return? >From InputStream in the API: read public abstract int read() throws IOExceptionReads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown. Value should be 0-255. In my application time is really critical, reading 1 byte at a time is probably not going to work. Thanks Eric & Bob for looking at this. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 14:44:50 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 13:44:50 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: Java's "char" type is Unicode. I think what you're seeing is a bug in the byte -> Unicode translation. 0x2018, 0x2019 are the curly open and close quotes. There used to be (and might still be) bugs in the conversion of these in a couple of libc versions. Some of the ASCII -> ISO and ISO -> ASCII routines were a little over-ambitious with respect to handling the open and close quotes, and tried to convert them to the "curly" form inappropriately. Try _not_ casting it to char. Bob At 11:26 AM -0500 3/3/07, Keith wrote: >Bob, > >> Interesting numerical coincidence is that (max USB transfer) - (what >> you get) = 4096-3968 = 128 bytes is (almost) the size of the headers >> needed to transfer that much data. > >I was thinking along the same lines. I don't know USB well, but I do know >that those numbers were close enough to warrant investigating the >relationship between them. > >> I think what you're seeing is the internal buffering of the USB data >> stream. You'll need some form of higher-level buffering to smooth >> that out. > >Shouldn't the InputStreamReader() and BufferedReader() provide this type of >buffering? Isn't that the idea behind those? > >> All hypotheses need to be tested. In this case, a test would be to >> check for missing data. If this idea is right, you'll get _all_ the >> data, but you won't be missing characters. > >I did start looking at the data. -- I'm getting weird results. > >I tried this: > >loopzz = 0; > >for (looptwo = 0; looptwo < 100000; looptwo++) { >while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > >}} > >So I'm reading one character at a time. The good news is that loopzz is >exactly 15238 at the end of the routine, which is perfectly correct. I >picked looptwo value out of thin air. > >The weird results come in terms of the values, the data isn't correct at >least in one case. Look here: > >0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > >This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). >But the 0x89 was replaced by 0x2030. Why the heck would the returned value >be 0x2030?? Why is the returned byte completely out of range? Why the >multibyte return? > >>From InputStream in the API: > >read >public abstract int read() > throws IOExceptionReads the next byte of data from the >input stream. The value byte is returned as an int in the range 0 to 255. If >no byte is available because the end of the stream has been reached, the >value -1 is returned. This method blocks until input data is available, the >end of the stream is detected, or an exception is thrown. >Value should be 0-255. > > >In my application time is really critical, reading 1 byte at a time is >probably not going to work. > >Thanks Eric & Bob for looking at this. > >Keith > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 15:10:11 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 17:10:11 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Bob said ..... > Java's "char" type is Unicode. I think what you're seeing is a bug > in the byte -> Unicode translation. Bob -- I think you hit the nail on the head. I was just coming to the same realization here. I knew that something funny was going on because the same bytes always got "corrupted." I'm pretty sure its in the InputStreamReader() functionality where the conversion junk is happening. Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. I don't know if simply changing the cast is going to work. Since the conversion is happening upstream (pun intended), I don't think my cast is doing this. Also I think the compiler forced me to use the cast. I'm still playing around, and I'll report back once I nail it down. Thanks!! Keith From tjarvi at qbang.org Sat Mar 3 15:59:46 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 15:59:46 -0700 (MST) Subject: [Rxtx] Win64 rxtx Testers? Message-ID: I have compiled win64 binaries of rxtx. Are there any users interested in testing them? If so, I'll look into putting them on the web site. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Mar 3 15:35:06 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 14:35:06 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: Because of this and similar problems, JMRI does all it's serial IO using +only+ byte values. It's a but of a pain, as Java wants to go to char and int types a little too aggressively, but it does solve the "uncontrolled conversions" problems. Bob At 5:10 PM -0500 3/3/07, Keith wrote: >Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > >Bob -- I think you hit the nail on the head. > >I was just coming to the same realization here. I knew that something funny >was going on because the same bytes always got "corrupted." > >I'm pretty sure its in the InputStreamReader() functionality where the >conversion junk is happening. > >Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > >I don't know if simply changing the cast is going to work. Since the >conversion is happening upstream (pun intended), I don't think my cast is >doing this. Also I think the compiler forced me to use the cast. -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mark at mdsh.com Sun Mar 4 11:01:33 2007 From: mark at mdsh.com (Mark Himsley) Date: Sun, 04 Mar 2007 18:01:33 +0000 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: <5C01AC72C200388815C04982@bedroom.mdsh.local> On 03 March 2007 14:38 -0500 Keith wrote: > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT > consistent. Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? It looks like you need to use DataInputStream and DataOutputStream. -- Mark Himsley From tjarvi at qbang.org Sun Mar 4 11:35:08 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 11:35:08 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" > > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > > * Line #21 - Not sure if you need a (TM) mark for > the term "Sun" > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > OK. I'm going through this today. Some groups ask if rxtx could be under their license also. I think this is a good example of why I resist multiple licenses and focus on why the current license may not be usable by them. The RXTX project is a convergence of hobby and commercial interests. I happen to do both right now. The problem with licensing is we have to stay on top of them as they change. Clearly, adding more licenses will not make this easier. I'm acting as the hobby person today. RXTX always favors the hobby people. But as we move forward, I'm going to need to bring this to lawyers at work and explain to them what is going on. Others here may have to do this also. I don't anticipate problems or unexpected changes. The goal is a consistant, comprehendable and usable license as close to what we have now as possible. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 14:52:10 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 14:52:10 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (1/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: I'm breaking this into two parts. I expect the second part will need more attention. Comments first, then the changed material below. On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > Thanks > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. OK. RXTX for consitent use. java should not be capitalized because it does not only mean Sun [TM] Java [TM]. An example of this not meaning Java is when people use RXTX with GCJ. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". There are not any contributors that are in all of RXTX yet but I did update the comment to try to reflect the current situation without making it a nightmare to maintain. I looked to see how the Linux kernel does it as a reference point. > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" The URL can be problematic. I have done so below with a time reference. GNU does not provide version information in their URLS. I picture this being a problem when the version 3 comes out. > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > This will be corrected when the copy is updated to the version linked below. ---------------- begin proposed material involved -------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. ----------------- end proposed material involved -------------------- I'll be looking at the linking issue again next. That should be all that remains other than including the 2.1 version. Let me know if you have problems with anything here. I do not want to dilute the material I post next with these housekeeping tasks. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 16:08:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 16:08:36 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: For those that are wondering what is going on here, this next bit is the meat of the changes. We agreed a long time ago to put this disclaimer in. We did a so so job. It was in rxtx 2.0, not well written, ... So some groups using rxtx that would like to ship rxtx so users don't need to download, install, go to the mail-list to find why it failed, ... Then their legal teams tell them section 5 paragraph 2 is a show stopper. That was never the intent. Now going through what remains... > and might need a (TM) suffix to make Sun happy. Added disclaimer at the ended 'all trademarks belong...' > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. OK. As you can see I was trying to adjust GNU text there for the LGPL. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. used dynamically linked terminology. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". I tried to address this more upfront with an intent statement. Let me know if you have problems with it. I also tried to make it a little more clear what was derived from the GNU solution by moving the link location closer to GNU's suggestion. > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > Thats the intent. Here is the combined fixes. Note that only the material in /*-- --*/ is being touched. The new GPL license is there but unmodified. ------------------------ begin proposed new license ------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. | | An executable that contains no derivative of any portion of RXTX, but | is designed to work with RXTX by being dynamically linked with it, | is considered a "work that uses the Library" subject to the terms and | conditions of the GNU Lesser General Public License. | | The following has been added to the RXTX License to remove | any confusion about linking to RXTX. We want to allow in part what | section 5, paragraph 2 of the LGPL does not permit in the special | case of linking over a controlled interface. The intent is to add a | Java Specification Request or standards body defined interface in the | future as another exception but one is not currently available. | | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface | | As a special exception, the copyright holders of RXTX give you | permission to link RXTX with independent modules that communicate with | RXTX solely through the Sun Microsytems CommAPI interface version 2, | regardless of the license terms of these independent modules, and to copy | and distribute the resulting combined work under terms of your choice, | provided that every copy of the combined work is accompanied by a complete | copy of the source code of RXTX (the version of RXTX used to produce the | combined work), being distributed under the terms of the GNU Lesser General | Public License plus this exception. An independent module is a | module which is not derived from or based on RXTX. | | Note that people who make modified versions of RXTX are not obligated | to grant this special exception for their modified versions; it is | their choice whether to do so. The GNU Lesser General Public License | gives permission to release a modified version without this exception; this | exception also makes it possible to release a modified version which | carries forward this exception. | | You should have received a copy of the GNU Lesser General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA | All trademarks belong to their respective owners. --------------------------------------------------------------------------*/ The original GNU Lesser General Public License Follows. GNU LESSER GENERAL PUBLIC LICENSE Version 2.1, February 1999 Copyright (C) 1991, 1999 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. [This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence the version number 2.1.] Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This license, the Lesser General Public License, applies to some specially designated software packages--typically libraries--of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below. When we speak of free software, we are referring to freedom of use, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish); that you receive source code or can get it if you want it; that you can change the software and use pieces of it in new free programs; and that you are informed that you can do these things. To protect your rights, we need to make restrictions that forbid distributors to deny you these rights or to ask you to surrender these rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library or if you modify it. For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights. We protect your rights with a two-step method: (1) we copyright the library, and (2) we offer you this license, which gives you legal permission to copy, distribute and/or modify the library. To protect each distributor, we want to make it very clear that there is no warranty for the free library. Also, if the library is modified by someone else and passed on, the recipients should know that what they have is not the original version, so that the original author's reputation will not be affected by problems that might be introduced by others. Finally, software patents pose a constant threat to the existence of any free program. We wish to make sure that a company cannot effectively restrict the users of a free program by obtaining a restrictive license from a patent holder. Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license. Most GNU software, including some libraries, is covered by the ordinary GNU General Public License. This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs. When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library. We call this license the "Lesser" General Public License because it does Less to protect the user's freedom than the ordinary General Public License. It also provides other free software developers Less of an advantage over competing non-free programs. These disadvantages are the reason we use the ordinary General Public License for many libraries. However, the Lesser license provides advantages in certain special circumstances. For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License. In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software. For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU operating system, as well as its variant, the GNU/Linux operating system. Although the Lesser General Public License is Less protective of the users' freedom, it does ensure that the user of a program that is linked with the Library has the freedom and the wherewithal to run that program using a modified version of the Library. The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, whereas the latter must be combined with the library in order to run. GNU LESSER GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License Agreement applies to any software library or other program which contains a notice placed by the copyright holder or other authorized party saying it may be distributed under the terms of this Lesser General Public License (also called "this License"). Each licensee is addressed as "you". A "library" means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables. The "Library", below, refers to any such software library or work which has been distributed under these terms. A "work based on the Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term "modification".) "Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library. Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does. 1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) The modified work must itself be a software library. b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change. c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License. d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful. (For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library. In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. 4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange. If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code. 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables. When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law. If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.) Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself. 6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications. You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things: a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.) b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. c) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution. d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place. e) Verify that the user has already received a copy of these materials or that you have already sent this user a copy. For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute. 7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things: a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above. b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work. 8. You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 9. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Library (or any work based on the Library), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Library or works based on it. 10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties with this License. 11. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply, and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 12. If the distribution and/or use of the Library is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Library under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 13. The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation. 14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Libraries If you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the ordinary General Public License). To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Also add information on how to contact you by electronic and paper mail. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the library, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the library `Frob' (a library for tweaking knobs) written by James Random Hacker. , 1 April 1990 Ty Coon, President of Vice That's all there is to it! ------------------------ end of proposed license ------------------ -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sun Mar 4 16:26:04 2007 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 04 Mar 2007 17:26:04 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <45EB558C.3010609@cox.net> Bob Jacobsen wrote: > Because of this and similar problems, JMRI does all it's serial IO > using +only+ byte values. It's a but of a pain, as Java wants to go > to char and int types a little too aggressively, but it does solve > the "uncontrolled conversions" problems. Anytime that you are reading bytes of data that is not printable, unicode text, in Java, you really need to stay away from the Readers. Use input stream only, or you will see unicode valued byte groups converted to unicode "char" values. Gregg Wonderly From joachim at buechse.de Mon Mar 5 04:23:48 2007 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 5 Mar 2007 12:23:48 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> The behaviour is exactly what you asked for in you code. is = new BufferedReader(new InputStreamReader(port.getInputStream())); Readers return Text (ie unicode chars) not bytes. You instantiate the InputStreamReader without saying which charset you want, which means "platform default". As this is on Windows, it will convert Windows characters to equivalent unicode characters. If you want to read bytes, read bytes not Text. Reading bytes is done with InputStream and BufferedInputStream. BTW: The InputStream and Reader methods that read arrays are not guarenteed to fill up the array. You always have to check what you really got, and advance your index accordingly. A typical "read up to 32k" method looks like this: InputStream is= ... // -- determine the max buffer size int len= is.available(); if (len == 0) { len= 32 * 1024; } // -- read all available data byte[] buffer= new byte[len]; int pos= 0; int read; do { read= is.read(buffer, pos, buffer.length - pos); pos= pos + read; } while (read != -1 && pos < buffer.length); Best regards, Joachim --- Joachim B?chse Phone: +41 44 500 2604 Buechse Consulting Hadlaubsteig 2 CH-8006 Z?rich On 03.03.2007, at 23:10, Keith wrote: > Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > > Bob -- I think you hit the nail on the head. > > I was just coming to the same realization here. I knew that > something funny > was going on because the same bytes always got "corrupted." > > I'm pretty sure its in the InputStreamReader() functionality where the > conversion junk is happening. > > Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > > I don't know if simply changing the cast is going to work. Since the > conversion is happening upstream (pun intended), I don't think my > cast is > doing this. Also I think the compiler forced me to use the cast. > > I'm still playing around, and I'll report back once I nail it down. > > Thanks!! > > Keith > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Mon Mar 5 07:25:46 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 05 Mar 2007 08:25:46 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> Message-ID: <45EC286A.8060608@cox.net> Joachim Buechse wrote: > BTW: The InputStream and Reader methods that read arrays are not > guarenteed to fill up the array. You always have to check what you > really got, and advance your index accordingly. A typical "read up to > 32k" method looks like this: > > InputStream is= ... > // -- determine the max buffer size > int len= is.available(); > if (len == 0) { > len= 32 * 1024; > } > // -- read all available data > byte[] buffer= new byte[len]; > int pos= 0; > int read; > do { > read= is.read(buffer, pos, buffer.length - pos); > pos= pos + read; > } while (read != -1 && pos < buffer.length); > My preferred structure is. byte arr[ len ]; int cnt; int off = 0; while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { off += cnt; } This keeps you from adding -1 to pos when the read returns -1. It also skips out when the read is 0 bytes which, is not a described EOF in InputStream java docs, but is a condition I want to be aware of. Gregg Wonderly From joachim at buechse.de Tue Mar 6 02:52:58 2007 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 6 Mar 2007 10:52:58 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <45EC286A.8060608@cox.net> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: The code I copied was from a file resource reader, it shouldn't really be applied to networking/external IO code. Mea culpa. However aborting when you get 0 from read is not always what you want either (you kind of indicated that already). Some unix java implementations will return 0 if the kernel read was aborted with EINTER, which is rarely the point where you want to abort your read - at least not without further checks. A "complete" solution always depends on the events you need to handle and the time the total read could take in reality. In some cases it's worth checking Thread.isInterrupted() in the loop, some code re-loops on 0 but only a limited number of times, some check a total timeout limit, etc... Best regards, Joachim On 05.03.2007, at 15:25, Gregg Wonderly wrote: > My preferred structure is. > > byte arr[ len ]; > int cnt; > int off = 0; > while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { > off += cnt; > } > > This keeps you from adding -1 to pos when the read returns -1. It > also skips > out when the read is 0 bytes which, is not a described EOF in > InputStream java > docs, but is a condition I want to be aware of. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Mar 6 14:47:44 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 Mar 2007 14:47:44 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: Just FYI, rxtx will usually not break out on EINTER. The code in the native library usually does something close to this: do { read(...) } while ( !done && errno==EINTR ); Obviously there is a little more involved but it will retry on EINTER if not done. On Tue, 6 Mar 2007, Joachim Buechse wrote: > The code I copied was from a file resource reader, it shouldn't > really be applied to networking/external IO code. Mea culpa. > > However aborting when you get 0 from read is not always what you want > either (you kind of indicated that already). Some unix java > implementations will return 0 if the kernel read was aborted with > EINTER, which is rarely the point where you want to abort your read - > at least not without further checks. A "complete" solution always > depends on the events you need to handle and the time the total read > could take in reality. In some cases it's worth checking > Thread.isInterrupted() in the loop, some code re-loops on 0 but only > a limited number of times, some check a total timeout limit, etc... > > Best regards, > Joachim > > On 05.03.2007, at 15:25, Gregg Wonderly wrote: >> My preferred structure is. >> >> byte arr[ len ]; >> int cnt; >> int off = 0; >> while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { >> off += cnt; >> } >> >> This keeps you from adding -1 to pos when the read returns -1. It >> also skips >> out when the read is 0 bytes which, is not a described EOF in >> InputStream java >> docs, but is a condition I want to be aware of. >> >> Gregg Wonderly >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 gjhanna at gmail.com Thu Mar 8 13:42:52 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Fri, 9 Mar 2007 09:42:52 +1300 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? Message-ID: I've just struck an issue using rxtx in a multi-threaded environment: If I have 3 threads trying to open *the same* comm-port I get a deadlock in CommPortIdentifier.open If I have just 2, it works fine - I get a PortInUseException which is nice and I can handle it. The 3 thread->deadlock thing is causing me issues. (Sample code below). This is from the java thread-dump Found one Java-level deadlock: ============================= "Thread-2": waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object ), which is held by "Thread-1" "Thread-1": waiting to lock monitor 0x0003e9cc (object 0x2450e108, a gnu.io.CommPortIdentifier), which is held by "Thread-2" Java stack information for the threads listed above: =================================================== "Thread-2": at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:329) - waiting to lock <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) "Thread-1": at java.lang.Object.wait(Native Method) - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) - locked <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) (Apart from this, rxtx is working fantastically for us). I'm thinking I'll have to implement some sort of locking mechanism that *doesn't* use java synchronization to prevent this situation. (Which doesn't sound like a good idea to me). Any ideas? Thanks, Greg Hanna ============= RXTXLockTest.java ======================================== import gnu.io.CommPort; import gnu.io.CommPortIdentifier; /** * @author Greg Hanna * Minimal code to create a deadlock with rxtx in multithreaded open */ public class RXTXLockTest { public static void main(String[] args) { try { CommPortIdentifier cpiCom1 = CommPortIdentifier.getPortIdentifier ("COM14"); OpenThread t1 = new OpenThread (" one ", cpiCom1); OpenThread t2 = new OpenThread (" two ", cpiCom1); OpenThread t3 = new OpenThread (" 003 ", cpiCom1); t1.start(); t2.start(); t3.start(); // comment this out and it runs with (expected) PortInUseException } catch (Exception e) { e.printStackTrace(); } } } class OpenThread extends Thread { String name; CommPortIdentifier cpi; CommPort cp; public OpenThread (String name, CommPortIdentifier cpi) { this.name = name; this.cpi = cpi; System.out.println (System.currentTimeMillis() + name + " thread created"); } public void run () { try { System.out.println (System.currentTimeMillis() + name + " opening"); cp = cpi.open(name, 2000); System.out.println (System.currentTimeMillis() + name + " opened - sleeping"); sleep (2000); // do the serial comms with the device. System.out.println (System.currentTimeMillis() + name + " slept - closing"); cp.close(); System.out.println (System.currentTimeMillis() + name + " closed - exiting"); } catch (Exception e) { System.out.println ("Error in thread: " + name ); e.printStackTrace(); } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070308/d9a163c5/attachment-0002.html From eu259473 at tele2.it Fri Mar 9 02:46:20 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 09 Mar 2007 10:46:20 +0100 Subject: [Rxtx] rxtx: tru64 unix make fails Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070309/3b654523/attachment-0002.html From lyon at docjava.com Fri Mar 9 03:58:32 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 Mar 2007 05:58:32 -0500 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi All, The deadlock issue is one that I have been thinking about for some time now. It seems to me that we need a resource manager that enables assignment to a known process. The one thing that seems important about serial ports is that two applications should not use the same serial port at the same time. When this happens, it throws an exception. OK. The exception is a response to a lock condition that arises from an unavailable resource. An abstract implementation (not born of native methods) might assign a serial port to an application, until the application releases it (or is forced to release it by some kill mechanism). Some resources (like a registry) can be reused. But others, like the serial port, cannot. In the case of the serial port, we would like, I think, to have the flyweight design pattern without sharing and with object assignment tracking. A means of breaking deadlock (like a leasing mechanism) seems very useful, to me. My guess is that we can serialize the state of the Parametric Singleton Pattern (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) into the Preferences of the System. Preferences.systemRoot() might help with that. When a resource is checked out, the lease time and owner are listed. A thread that does this can be killed, but applications outside of Java are problematic. There is a compelling problem here. It is not just serial ports. Sound cards, cameras, microphones, files, tape drives, etc. All are consumed resources that are assigned to an application (or user) and deprive other applications, or users, from use. What, if anything, should we do? At present we throw PortInUseExceptions. Is that it? Can we do better? OK, the port is in use. Now what? Do I have to be root to go remove lock files and kill applications? Is there a better way? Thanks! - Doug >I've just struck an issue using rxtx in a multi-threaded environment: > >If I have 3 threads trying to open *the same* >comm-port I get a deadlock in >CommPortIdentifier.open >If I have just 2, it works fine - I get a >PortInUseException which is nice and I can >handle it. > >The 3 thread->deadlock thing is causing me issues. >(Sample code below). > >This is from the java thread-dump > >Found one Java-level deadlock: >============================= >"Thread-2": > waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), > which is held by "Thread-1" >"Thread-1": > waiting to lock monitor 0x0003e9cc (object >0x2450e108, a gnu.io.CommPortIdentifier ), > which is held by "Thread-2" > >Java stack information for the threads listed above: >=================================================== >"Thread-2": > at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) > - waiting to lock <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) >"Thread-1": > at java.lang.Object.wait(Native Method) > - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) > - locked <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) > > >(Apart from this, rxtx is working fantastically for us). > >I'm thinking I'll have to implement some sort of >locking mechanism that *doesn't* use java >synchronization to prevent this situation. >(Which doesn't sound like a good idea to me). > >Any ideas? > >Thanks, > >Greg Hanna > >============= RXTXLockTest.java ======================================== > >import gnu.io.CommPort; >import gnu.io.CommPortIdentifier; > >/** > * @author Greg Hanna > * Minimal code to create a deadlock with rxtx in multithreaded open > */ >public class RXTXLockTest { > ? > ?public static void main(String[] args) { > ?try { > ?CommPortIdentifier cpiCom1 = >CommPortIdentifier.getPortIdentifier ("COM14"); > ?OpenThread t1 = new OpenThread (" one ", cpiCom1); > ?OpenThread t2 = new OpenThread (" two ", cpiCom1); > ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); > ?t1.start(); > ?t2.start(); > ?t3.start(); // comment this out >and it runs with (expected) PortInUseException > ?} catch (Exception e) { > ?e.printStackTrace(); > ?} > ?} >} > >class OpenThread extends Thread { > ?String name; > ?CommPortIdentifier cpi; > ?CommPort cp; > ?public OpenThread (String name, CommPortIdentifier cpi) { > ? this.name = name; > ?this.cpi = cpi; > ?System.out.println >(System.currentTimeMillis() + name + " thread >created"); > ?} > ?public void run () { > ?try { > ?System.out.println >(System.currentTimeMillis() + name + " opening"); > ?cp = cpi.open(name, 2000); > ?System.out.println >(System.currentTimeMillis() + name + " opened - >sleeping"); > ?sleep (2000); // do the serial comms with the device. > ?System.out.println >(System.currentTimeMillis() + name + " slept - >closing"); > ?cp.close(); > ?System.out.println >(System.currentTimeMillis() + name + " closed - >exiting"); > ?} catch (Exception e) { > System.out.println ("Error in thread: " + name ); > ?e.printStackTrace(); > ?} > ?} >} > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Mar 9 06:37:45 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 Mar 2007 06:37:45 -0700 (MST) Subject: [Rxtx] rxtx: tru64 unix make fails In-Reply-To: References: Message-ID: On Fri, 9 Mar 2007, "Giuseppe Marchese" wrote: > Sorry for delay. > ? > This is log for ./configure and make > error. > ? > thanks for attention > ? > Make: '%.java,$(TOP)/$(CLASSDEST)/%.class,$(wildcard $(SPATH)/*.java)': extra chars.? > Stop. > Hi Giuseppe You need to use GNU make with the Makefile. I suspect the tru64 make is not happy with those rules. > configure: exit 0 Looks like configure is fairly happy. From tjarvi at qbang.org Sat Mar 10 07:43:51 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 07:43:51 -0700 (MST) Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi Doug I have very little time to look into this further but what we could do is open up an rxtx 3 devel branch in which a proof of concept could be worked on. It could be the proof of concept for a JSR others including Sun could look at/work on or parts of it could be recycled in a JSR. I'm working very hard on rxtx right now but it does not show. I'm looking at win64, mac intel/ppc, usb bluetooth and usb serial dongles. Some are going to be more tested than others but they are all on the plate. I'll be pushing all the fixes upstream when they are done. So I'm very busy in 2.1 but we could open a new branch. On Fri, 9 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > The deadlock issue is one that I have been thinking about > for some time now. > It seems to me that we need a resource manager that enables assignment > to a known process. > > The one thing that seems important about serial > ports is that two applications should not use the > same serial port at the same time. When this > happens, it throws an exception. > OK. > > The exception is a response to a lock condition that > arises from an unavailable resource. > > An abstract implementation (not born of native methods) might > assign a serial port to an application, until the > application releases it (or is forced to release > it by some kill mechanism). > > Some resources (like a registry) can be reused. > But others, like the serial port, > cannot. > > In the case of the serial port, we would like, I think, to > have the flyweight design pattern > without sharing and with object assignment tracking. > A means of breaking deadlock (like a leasing > mechanism) seems very useful, to me. > > My guess is that we can serialize the state of the Parametric Singleton Pattern > (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) > into the Preferences of the System. Preferences.systemRoot() might help > with that. When a resource is checked out, the lease time and owner are > listed. A thread that does this can be killed, but applications outside of Java > are problematic. > > There is a compelling problem here. It is not just serial ports. > Sound cards, cameras, microphones, files, tape drives, etc. All are consumed > resources that are assigned to an application (or > user) and deprive other applications, > or users, from use. > > What, if anything, should we do? At present we throw PortInUseExceptions. > Is that it? > Can we do better? > OK, the port is in use. Now what? > Do I have to be root to go remove lock files and kill applications? > Is there a better way? > > Thanks! > - Doug > >> I've just struck an issue using rxtx in a multi-threaded environment: >> >> If I have 3 threads trying to open *the same* >> comm-port I get a deadlock in >> CommPortIdentifier.open >> If I have just 2, it works fine - I get a >> PortInUseException which is nice and I can >> handle it. >> >> The 3 thread->deadlock thing is causing me issues. >> (Sample code below). >> >> This is from the java thread-dump >> >> Found one Java-level deadlock: >> ============================= >> "Thread-2": >> waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), >> which is held by "Thread-1" >> "Thread-1": >> waiting to lock monitor 0x0003e9cc (object >> 0x2450e108, a gnu.io.CommPortIdentifier ), >> which is held by "Thread-2" >> >> Java stack information for the threads listed above: >> =================================================== >> "Thread-2": >> at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) >> - waiting to lock <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> "Thread-1": >> at java.lang.Object.wait(Native Method) >> - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) >> - locked <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> >> >> (Apart from this, rxtx is working fantastically for us). >> >> I'm thinking I'll have to implement some sort of >> locking mechanism that *doesn't* use java >> synchronization to prevent this situation. >> (Which doesn't sound like a good idea to me). >> >> Any ideas? >> >> Thanks, >> >> Greg Hanna >> >> ============= RXTXLockTest.java ======================================== >> >> import gnu.io.CommPort; >> import gnu.io.CommPortIdentifier; >> >> /** >> * @author Greg Hanna >> * Minimal code to create a deadlock with rxtx in multithreaded open >> */ >> public class RXTXLockTest { >> ? >> ?public static void main(String[] args) { >> ?try { >> ?CommPortIdentifier cpiCom1 = >> CommPortIdentifier.getPortIdentifier ("COM14"); >> ?OpenThread t1 = new OpenThread (" one ", cpiCom1); >> ?OpenThread t2 = new OpenThread (" two ", cpiCom1); >> ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); >> ?t1.start(); >> ?t2.start(); >> ?t3.start(); // comment this out >> and it runs with (expected) PortInUseException >> ?} catch (Exception e) { >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> class OpenThread extends Thread { >> ?String name; >> ?CommPortIdentifier cpi; >> ?CommPort cp; >> ?public OpenThread (String name, CommPortIdentifier cpi) { >> ? this.name = name; >> ?this.cpi = cpi; >> ?System.out.println >> (System.currentTimeMillis() + name + " thread >> created"); >> ?} >> ?public void run () { >> ?try { >> ?System.out.println >> (System.currentTimeMillis() + name + " opening"); >> ?cp = cpi.open(name, 2000); >> ?System.out.println >> (System.currentTimeMillis() + name + " opened - >> sleeping"); >> ?sleep (2000); // do the serial comms with the device. >> ?System.out.println >> (System.currentTimeMillis() + name + " slept - >> closing"); >> ?cp.close(); >> ?System.out.println >> (System.currentTimeMillis() + name + " closed - >> exiting"); >> ?} catch (Exception e) { >> System.out.println ("Error in thread: " + name ); >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 mm at UDel.Edu Sat Mar 10 14:48:32 2007 From: mm at UDel.Edu (Mike Markowski) Date: Sat, 10 Mar 2007 16:48:32 -0500 Subject: [Rxtx] rxtx and Sun's comm api Message-ID: <45F327B0.2060004@udel.edu> Hi all, I joined the list a few days ago and apologize for what is likely a frequently asked question, though I haven't yet found it anywhere. I learned about rxtx.org through the readme on Sun's version 2 of their comms api. They give recommendations in that readme regarding how a better comms api should be written. Is this the aim of rxtx.org? I wrote an app on my linux box using the Sun comms api (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the fact that only linux and Solaris are supported. So I'm glad to find rxtx.org and am just reading up on how make the conversion so Windows users will be able to run the program as well. At the same time I'm just curious if rxtx.org and Sun are both heading in the same direction. Thanks for any background or historical info. Feel free to point me to any www pages if my googling has just completely missed the target! Thanks again, Mike From tjarvi at qbang.org Sat Mar 10 15:35:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 15:35:25 -0700 (MST) Subject: [Rxtx] rxtx and Sun's comm api In-Reply-To: <45F327B0.2060004@udel.edu> References: <45F327B0.2060004@udel.edu> Message-ID: On Sat, 10 Mar 2007, Mike Markowski wrote: > Hi all, > > I joined the list a few days ago and apologize for what is likely a > frequently asked question, though I haven't yet found it anywhere. I > learned about rxtx.org through the readme on Sun's version 2 of their > comms api. They give recommendations in that readme regarding how a > better comms api should be written. Is this the aim of rxtx.org? > > I wrote an app on my linux box using the Sun comms api > (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the > fact that only linux and Solaris are supported. So I'm glad to find > rxtx.org and am just reading up on how make the conversion so Windows > users will be able to run the program as well. At the same time I'm > just curious if rxtx.org and Sun are both heading in the same direction. > > Thanks for any background or historical info. Feel free to point me to > any www pages if my googling has just completely missed the target! > I do not have any news (good or bad) concerning RXTX and Sun working together but perhaps others here do. The main goal of RXTX is to expose POSIX termios interfaces to java users. The future support of javax.comm is questionable. We do not have resources for everything. gnu.io (RXTX 2.1) will be supported going forward and functions the same as CommAPI 2.0. If you have control of the source code you are working with, I would not advise using CommAPI 2.0 javax.comm. We do support CommAPI 2.0 javax.comm for older applications but I do not think that will last much longer for practical reasons. The download interest in CommAPI 2.0 javax.comm support is becomming negligible on this end. There has been discussion of a JSR effort but I do not know of any status change since it was mentioned. One problem with a JSR is that even a light weight process is going to be difficult for RXTX at this time. Maybe that will change in the future but then again it may not. For now, we are just going forward 'as is' in rxtx 2.1 with package gnu.io while trying as a secondary effort to backport the changes to rxtx 2.0 for javax.comm support for users that do not have a choice. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Mar 11 07:19:40 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 11 Mar 2007 08:19:40 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: Hi All, I have been a proponent of a JSR that makes use of RXTX. I have executed the proper agreements with Sun. At this point we are in the: Early Draft Review of Draft Specifications Stage. The best thing to do is to enter the quiet period and create a specification. The question of exactly how we, as a group, want to approach this problem, remains open. Typically, we should have both a specification and a reference implementation. Thus, it would be to our best advantage to have a nice, stable, cross platform RXTX distro that adheres to the groups specification. Now, from a specification standpoint, my personal view on the matter is that we create a series of interfaces, with nice documentation (or at least javadoc). Is this a good idea? Should we have a pure interface specification for the communication API? There are several issues, in my mind, which still weigh on us. Hot-pluggable dongles, long discovery process on pop-up ports, lack of uniformity on device names, lack of uniformity on locking, a precise understanding of how the SerialPortResourceManager works (or even if we should have one). The more questions we answer in our reference implementation, the better our specification will get. RXTX is a good working prototype, but, I don't know if that is what we want to use for a specification. Here is what I have for a CommPortInterface: */ public interface CommPortInterface { /** * @return a string representation of this port. */ String toString(); /** * Gets the name of the communications port. This name should correspond to * something the user can identify, like the label on the hardware. * @return name of the port */ String getName(); /** * @return an input stream that can be used to read data from the * communications port. If the port doesn't support reading data, this * method returns null. *

* The blocking behaviour of this input stream depends on the threshold * and timeout values, as shown below for a read buffer size of n * bytes: * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ThresholdTimeoutBlocking behaviour
StateValueStateValue
disableddisabledblock until data is available
enabledm bytesdisabledblock until min(m, n) bytes are available
disabledenabledt msblock for t ms or until data is available
enabledm bytesenabledt msblock for t ms or until min(m, n) bytes are * available
* @throws java.io.IOException */ InputStream getInputStream() throws IOException; /** * @return an output stream that can be used to send data to the * communications port. If the port doesn't support sending data, this * method returns null. * @throws java.io.IOException */ OutputStream getOutputStream() throws IOException; /** * Closes this communications port. * All PortOwnershipListeners will be? * notified of this change of ownership. Further method calls on this? * object will throw IllegalStateException. Further calls on the? * associated InputStream or OutputStream will throw IOException. *

* Close does not block. Undelivered data is discarded. Blocked read and? * write operations are aborted if the underlying operating systems? * supports an IO abort mechanism. To await the delivery of undelivered? * data call OutputStream.flush() or OutputStream.close() before calling? * Port.close(). */ void close(); /** * Enables receive threshold. * When the specified threshold number of bytes are retrieved, read will * return immediately. * * @param thresh the number of bytes in the input buffer * @throws gnu.io.UnsupportedCommOperationException * if receive threshold is * not supported by the driver * @see #disableReceiveThreshold */ void enableReceiveThreshold(int thresh) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive threshold. * * @see #enableReceiveThreshold */ void disableReceiveThreshold(); /** * @return true if receive threshold is enabled. * * @see #enableReceiveThreshold */ boolean isReceiveThresholdEnabled(); /** * @return the receive threshold value. If receive threshold is diabled * or not supported, this value is meaningless. * * @see #enableReceiveThreshold */ int getReceiveThreshold(); /** * Enables receive timeout. * When the specified number of milliseconds have elapsed, read will * return immediately. * * @param rcvTimeout the number of milliseconds to block for * @throws gnu.io.UnsupportedCommOperationException * if receive timeout is * not supported by the driver * @see #disableReceiveTimeout */ void enableReceiveTimeout(int rcvTimeout) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive timeout. * * @see #enableReceiveTimeout */ void disableReceiveTimeout(); /** * @return true if receive timeout is enabled. * * @see #enableReceiveTimeout */ boolean isReceiveTimeoutEnabled(); /** * @return the receive timeout value. If receive timeout is diabled * or not supported, this value is meaningless. * * @see #enableReceiveTimeout */ int getReceiveTimeout(); /** * Enables receive framing. * The supplied byte value in the input suggests the end of the received * frame, and read returns immediately. Only the low 8 bits of the * supplied value are significant. * * @param framingByte the frame delimiter * @throws gnu.io.UnsupportedCommOperationException * if receive framing is * not supported by the driver * @see #disableReceiveFraming */ void enableReceiveFraming(int framingByte) throws UnsupportedCommOperationException; /** * Disables receive framing. * * @see #enableReceiveFraming */ void disableReceiveFraming(); /** * @return true if receive framing is enabled. * * @see #enableReceiveFraming */ boolean isReceiveFramingEnabled(); /** * @return true if receive framing byte. If receive framing is diabled * or not supported, this value is meaningless. * * @see #enableReceiveFraming */ int getReceiveFramingByte(); /** * Sets the input buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setInputBufferSize(int size); /** * @return the input buffer size. * The driver may choose not to report correct values. */ int getInputBufferSize(); /** * Sets the output buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setOutputBufferSize(int size); /** * @return the output buffer size. * The driver may choose not to report correct values. */ int getOutputBufferSize(); } What do you think of that? Note the wishy washy nature of the spec: The driver may choose to ignore this method. Is that good enough for us? Thanks! - Doug From ra85551 at gmail.com Sun Mar 11 08:44:45 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Sun, 11 Mar 2007 17:44:45 +0300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hello, world! I am writing application that communicates with modem via AT commands. My OS is Linux Kubuntu Feisty Herd, to ensure that my application will run properly under Windows XP I installed VMWare server. When I tried to send AT command and evaluate modem answer under WinXP @ VMWare server, I actually didn't receive anything. I think that VM settings are right, because I do can communicate with modem by using standard HyperTerminall as well as I can do on native Windows. So, why RXTX doesn't work under VM, but works under Linux and pure Windows XP (i tested it there) well? The send/receive method code follows. private String sendATCommand(String command, final String waitFor, final boolean isRegex, boolean isAddCRLF, long timeout) throws BeaconConnectException { final long POLL_PERIOD = 100; final int BUFFER_SIZE = 512; final byte[] buffer = new byte[BUFFER_SIZE]; final InputStream serialInput; final OutputStream serialOutput; try { serialInput = serialPort.getInputStream(); if (command != null) { serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } } catch (IOException e) { throw new MyException("serial I/O error"); } TimerTask task = new TimerTask() { int offset = 0; int bytesRead; public synchronized void run() { try { if (serialInput.available() > 0) { bytesRead = serialInput.read(buffer, offset, BUFFER_SIZE - offset); } else { return; } } catch (IOException e) { // do nothing - maybe next time we'll read something } offset += bytesRead; if (waitFor != null) { String temporary = new String(buffer, 0, offset).trim(); if (isRegex && temporary.matches(waitFor) || temporary.contains(waitFor)) { cancel(); notify(); } } } }; Timer timer = new Timer(); timer.schedule(task, POLL_PERIOD, POLL_PERIOD); synchronized (task) { try { task.wait(timeout); task.cancel(); } catch (InterruptedException e) { } } //Cut off leading and trailing CRs, LFs and zeroes String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); System.out.println(response); return response; } -- Pavel Parkhomenko From tjarvi at qbang.org Sun Mar 11 11:48:22 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:48:22 -0600 (MDT) Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: On Sun, 11 Mar 2007, Pavel Parkhomenko wrote: > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. > > private String sendATCommand(String command, final String waitFor, > final boolean isRegex, boolean isAddCRLF, long timeout) > throws BeaconConnectException > { > final long POLL_PERIOD = 100; > final int BUFFER_SIZE = 512; > final byte[] buffer = new byte[BUFFER_SIZE]; > final InputStream serialInput; > final OutputStream serialOutput; > try > { > serialInput = serialPort.getInputStream(); > if (command != null) > { > serialOutput = serialPort.getOutputStream(); > if (isAddCRLF) > { > command += "\r\n"; > } > System.out.println(command); > serialOutput.write(command.getBytes()); > } > } > catch (IOException e) > { > throw new MyException("serial I/O error"); > } > > TimerTask task = new TimerTask() > { > int offset = 0; > int bytesRead; > public synchronized void run() > { > try > { > if (serialInput.available() > 0) > { > bytesRead = serialInput.read(buffer, offset, > BUFFER_SIZE - offset); > } > else > { > return; > } > } > catch (IOException e) > { > // do nothing - maybe next time we'll read something > } > offset += bytesRead; > if (waitFor != null) > { > String temporary = new String(buffer, 0, offset).trim(); > if (isRegex && temporary.matches(waitFor) || > temporary.contains(waitFor)) > { > cancel(); > notify(); > } > } > } > }; > > Timer timer = new Timer(); > timer.schedule(task, POLL_PERIOD, POLL_PERIOD); > synchronized (task) { > try > { > task.wait(timeout); > task.cancel(); > } > catch (InterruptedException e) > { > } > } > //Cut off leading and trailing CRs, LFs and zeroes > String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); > System.out.println(response); > return response; > } > > > Hi Pavel VMWare should not be a problem. I've used it in the past - though not with a modem. Make sure nothing else is using the modem. Then look in the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an example that should work. Note that modems could care less what OS is on top. If you are trying to match new lines to the OS and sending it to the mode for AT commands, thats probably a mistake. Also it would not hurt to print out the individual bytes that you are sending to make sure they did not get mangled along the path. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 11:55:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:55:48 -0600 (MDT) Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: On Sun, 11 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > I have been a proponent of a JSR that makes > use of RXTX. I have executed the proper agreements with Sun. > > At this point we are in the: > Early Draft Review of Draft Specifications Stage. > > The best thing to do is to enter the quiet period and create > a specification. The question of exactly how we, as a group, > want to approach this problem, remains open. > > Typically, we should have both a specification and a reference > implementation. Thus, it would be to our best advantage to have > a nice, stable, cross platform RXTX distro that adheres to the > groups specification. > > Now, from a specification standpoint, my personal view on the matter is > that we create a series of interfaces, with nice documentation (or at least > javadoc). > > Is this a good idea? Should we have a pure interface specification for > the communication API? > > There are several issues, in my mind, which still weigh on us. > Hot-pluggable dongles, long discovery process on pop-up ports, > lack of uniformity on device names, lack of uniformity on locking, > a precise understanding of how the SerialPortResourceManager > works (or even if we should have one). > > The more questions we answer in our reference implementation, the > better our specification will get. RXTX is a good working prototype, > but, I don't know if that is what we want to use for a specification. > > Here is what I have for a CommPortInterface: > */ > public interface CommPortInterface { Hi Doug, I can start going through the method interfaces later this week and giving feedback. I would suggest that the JSR should not be too generic in nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel drivers that intend to look like EIA232 ports at the kernel driver level. some ideas: EIA232PortInterface TermiosInterface SerialPortInterface Something that differentiates this from thing like USB, I2C, ... which should not have to deal with legacy serial claiming to be the comm api. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 12:52:19 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 12:52:19 -0600 (MDT) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: No news is good news with these posts. I'll start the process of pinging legal a week from Monday on my end if nobody has objections to the proposal. I just want to make sure everyone has time to raise objections. Obviously, anyone can fork from a previous version if they don't like the new license. I suspect we can avoid that though. On Sun, 4 Mar 2007, Trent Jarvi wrote: > > For those that are wondering what is going on here, this > next bit is the meat of the changes. We agreed a long time > ago to put this disclaimer in. We did a so so job. It was > in rxtx 2.0, not well written, ... So some groups using > rxtx that would like to ship rxtx so users don't need to > download, install, go to the mail-list to find why it failed, > ... Then their legal teams tell them section 5 paragraph 2 > is a show stopper. > > That was never the intent. > > > Now going through what remains... > >> and might need a (TM) suffix to make Sun happy. > > Added disclaimer at the ended 'all trademarks belong...' > >> * Line #15ff - static vs. dynamic linking - you did >> not transcribe the text from the "controlled >> interface exception" when writing this text - and >> this was good so, because these terms originally >> refer to the GPL rather than the LGPL. I think though, >> that these 4 lines are the most important ones and >> should thus be really really clear. I hope that I >> meet your original intent with the following >> suggestions: >> 1.) Instead of "A program.." it would be better to >> say "An exectuable.." in order to be closer to >> the LGPL text. > > OK. As you can see I was trying to adjust GNU text there > for the LGPL. > >> 2.) It would be better to say .. "by being dynamically >> linked with it" to clearly indicate that dynamic >> linking is meant. The matter of compilation is >> already covered by the LGPL so mentioning it again >> just leads to confusion. > > used dynamically linked terminology. > >> 3.) It would be better to say .. "is considered a >> work that uses the library in contrast to section >> 5 of the LGPL, so the terms of the LGPL do not >> apply to the resulting executable". > > I tried to address this more upfront with an intent statement. > Let me know if you have problems with it. I also tried to > make it a little more clear what was derived from the GNU > solution by moving the link location closer to GNU's suggestion. > >> >> Note that LGPL section 5 says: ..."is called a >> "work that uses the Library". Such a work, in isolation, >> is not a derivative work of the Library, and therefore >> falls outside the scope of this License." >> The next paragraph of the LGPL is exactly the problematic >> one that I hope is clarified by the exception terms you >> give. >> > > Thats the intent. Here is the combined fixes. Note that only the > material in /*-- --*/ is being touched. The new GPL license is > there but unmodified. > > > ------------------------ begin proposed new license ------------------- > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Lesser General Public > | License as published by the Free Software Foundation; either > | version 2.1 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Lesser General Public License for more details. > | > | An executable that contains no derivative of any portion of RXTX, but > | is designed to work with RXTX by being dynamically linked with it, > | is considered a "work that uses the Library" subject to the terms and > | conditions of the GNU Lesser General Public License. > | > | The following has been added to the RXTX License to remove > | any confusion about linking to RXTX. We want to allow in part what > | section 5, paragraph 2 of the LGPL does not permit in the special > | case of linking over a controlled interface. The intent is to add a > | Java Specification Request or standards body defined interface in the > | future as another exception but one is not currently available. > | > | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface > | > | As a special exception, the copyright holders of RXTX give you > | permission to link RXTX with independent modules that communicate with > | RXTX solely through the Sun Microsytems CommAPI interface version 2, > | regardless of the license terms of these independent modules, and to copy > | and distribute the resulting combined work under terms of your choice, > | provided that every copy of the combined work is accompanied by a complete > | copy of the source code of RXTX (the version of RXTX used to produce the > | combined work), being distributed under the terms of the GNU Lesser General > | Public License plus this exception. An independent module is a > | module which is not derived from or based on RXTX. > | > | Note that people who make modified versions of RXTX are not obligated > | to grant this special exception for their modified versions; it is > | their choice whether to do so. The GNU Lesser General Public License > | gives permission to release a modified version without this exception; this > | exception also makes it possible to release a modified version which > | carries forward this exception. > | > | You should have received a copy of the GNU Lesser General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > | All trademarks belong to their respective owners. > --------------------------------------------------------------------------*/ > > The original GNU Lesser General Public License Follows. > > > GNU LESSER GENERAL PUBLIC LICENSE > Version 2.1, February 1999 > > Copyright (C) 1991, 1999 Free Software Foundation, Inc. > 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > Everyone is permitted to copy and distribute verbatim copies > of this license document, but changing it is not allowed. > > [This is the first released version of the Lesser GPL. It also counts > as the successor of the GNU Library Public License, version 2, hence > the version number 2.1.] > > Preamble > > The licenses for most software are designed to take away your > freedom to share and change it. By contrast, the GNU General Public > Licenses are intended to guarantee your freedom to share and change > free software--to make sure the software is free for all its users. > > This license, the Lesser General Public License, applies to some > specially designated software packages--typically libraries--of the > Free Software Foundation and other authors who decide to use it. You > can use it too, but we suggest you first think carefully about whether > this license or the ordinary General Public License is the better > strategy to use in any particular case, based on the explanations below. > > When we speak of free software, we are referring to freedom of use, > not price. Our General Public Licenses are designed to make sure that > you have the freedom to distribute copies of free software (and charge > for this service if you wish); that you receive source code or can get > it if you want it; that you can change the software and use pieces of > it in new free programs; and that you are informed that you can do > these things. > > To protect your rights, we need to make restrictions that forbid > distributors to deny you these rights or to ask you to surrender these > rights. These restrictions translate to certain responsibilities for > you if you distribute copies of the library or if you modify it. > > For example, if you distribute copies of the library, whether gratis > or for a fee, you must give the recipients all the rights that we gave > you. You must make sure that they, too, receive or can get the source > code. If you link other code with the library, you must provide > complete object files to the recipients, so that they can relink them > with the library after making changes to the library and recompiling > it. And you must show them these terms so they know their rights. > > We protect your rights with a two-step method: (1) we copyright the > library, and (2) we offer you this license, which gives you legal > permission to copy, distribute and/or modify the library. > > To protect each distributor, we want to make it very clear that > there is no warranty for the free library. Also, if the library is > modified by someone else and passed on, the recipients should know > that what they have is not the original version, so that the original > author's reputation will not be affected by problems that might be > introduced by others. > > Finally, software patents pose a constant threat to the existence of > any free program. We wish to make sure that a company cannot > effectively restrict the users of a free program by obtaining a > restrictive license from a patent holder. Therefore, we insist that > any patent license obtained for a version of the library must be > consistent with the full freedom of use specified in this license. > > Most GNU software, including some libraries, is covered by the > ordinary GNU General Public License. This license, the GNU Lesser > General Public License, applies to certain designated libraries, and > is quite different from the ordinary General Public License. We use > this license for certain libraries in order to permit linking those > libraries into non-free programs. > > When a program is linked with a library, whether statically or using > a shared library, the combination of the two is legally speaking a > combined work, a derivative of the original library. The ordinary > General Public License therefore permits such linking only if the > entire combination fits its criteria of freedom. The Lesser General > Public License permits more lax criteria for linking other code with > the library. > > We call this license the "Lesser" General Public License because it > does Less to protect the user's freedom than the ordinary General > Public License. It also provides other free software developers Less > of an advantage over competing non-free programs. These disadvantages > are the reason we use the ordinary General Public License for many > libraries. However, the Lesser license provides advantages in certain > special circumstances. > > For example, on rare occasions, there may be a special need to > encourage the widest possible use of a certain library, so that it becomes > a de-facto standard. To achieve this, non-free programs must be > allowed to use the library. A more frequent case is that a free > library does the same job as widely used non-free libraries. In this > case, there is little to gain by limiting the free library to free > software only, so we use the Lesser General Public License. > > In other cases, permission to use a particular library in non-free > programs enables a greater number of people to use a large body of > free software. For example, permission to use the GNU C Library in > non-free programs enables many more people to use the whole GNU > operating system, as well as its variant, the GNU/Linux operating > system. > > Although the Lesser General Public License is Less protective of the > users' freedom, it does ensure that the user of a program that is > linked with the Library has the freedom and the wherewithal to run > that program using a modified version of the Library. > > The precise terms and conditions for copying, distribution and > modification follow. Pay close attention to the difference between a > "work based on the library" and a "work that uses the library". The > former contains code derived from the library, whereas the latter must > be combined with the library in order to run. > > GNU LESSER GENERAL PUBLIC LICENSE > TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION > > 0. This License Agreement applies to any software library or other > program which contains a notice placed by the copyright holder or > other authorized party saying it may be distributed under the terms of > this Lesser General Public License (also called "this License"). > Each licensee is addressed as "you". > > A "library" means a collection of software functions and/or data > prepared so as to be conveniently linked with application programs > (which use some of those functions and data) to form executables. > > The "Library", below, refers to any such software library or work > which has been distributed under these terms. A "work based on the > Library" means either the Library or any derivative work under > copyright law: that is to say, a work containing the Library or a > portion of it, either verbatim or with modifications and/or translated > straightforwardly into another language. (Hereinafter, translation is > included without limitation in the term "modification".) > > "Source code" for a work means the preferred form of the work for > making modifications to it. For a library, complete source code means > all the source code for all modules it contains, plus any associated > interface definition files, plus the scripts used to control compilation > and installation of the library. > > Activities other than copying, distribution and modification are not > covered by this License; they are outside its scope. The act of > running a program using the Library is not restricted, and output from > such a program is covered only if its contents constitute a work based > on the Library (independent of the use of the Library in a tool for > writing it). Whether that is true depends on what the Library does > and what the program that uses the Library does. > > 1. You may copy and distribute verbatim copies of the Library's > complete source code as you receive it, in any medium, provided that > you conspicuously and appropriately publish on each copy an > appropriate copyright notice and disclaimer of warranty; keep intact > all the notices that refer to this License and to the absence of any > warranty; and distribute a copy of this License along with the > Library. > > You may charge a fee for the physical act of transferring a copy, > and you may at your option offer warranty protection in exchange for a > fee. > > 2. You may modify your copy or copies of the Library or any portion > of it, thus forming a work based on the Library, and copy and > distribute such modifications or work under the terms of Section 1 > above, provided that you also meet all of these conditions: > > a) The modified work must itself be a software library. > > b) You must cause the files modified to carry prominent notices > stating that you changed the files and the date of any change. > > c) You must cause the whole of the work to be licensed at no > charge to all third parties under the terms of this License. > > d) If a facility in the modified Library refers to a function or a > table of data to be supplied by an application program that uses > the facility, other than as an argument passed when the facility > is invoked, then you must make a good faith effort to ensure that, > in the event an application does not supply such function or > table, the facility still operates, and performs whatever part of > its purpose remains meaningful. > > (For example, a function in a library to compute square roots has > a purpose that is entirely well-defined independent of the > application. Therefore, Subsection 2d requires that any > application-supplied function or table used by this function must > be optional: if the application does not supply it, the square > root function must still compute square roots.) > > These requirements apply to the modified work as a whole. If > identifiable sections of that work are not derived from the Library, > and can be reasonably considered independent and separate works in > themselves, then this License, and its terms, do not apply to those > sections when you distribute them as separate works. But when you > distribute the same sections as part of a whole which is a work based > on the Library, the distribution of the whole must be on the terms of > this License, whose permissions for other licensees extend to the > entire whole, and thus to each and every part regardless of who wrote > it. > > Thus, it is not the intent of this section to claim rights or contest > your rights to work written entirely by you; rather, the intent is to > exercise the right to control the distribution of derivative or > collective works based on the Library. > > In addition, mere aggregation of another work not based on the Library > with the Library (or with a work based on the Library) on a volume of > a storage or distribution medium does not bring the other work under > the scope of this License. > > 3. You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. To do > this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version 2, > instead of to this License. (If a newer version than version 2 of the > ordinary GNU General Public License has appeared, then you can specify > that version instead if you wish.) Do not make any other change in > these notices. > > Once this change is made in a given copy, it is irreversible for > that copy, so the ordinary GNU General Public License applies to all > subsequent copies and derivative works made from that copy. > > This option is useful when you wish to copy part of the code of > the Library into a program that is not a library. > > 4. You may copy and distribute the Library (or a portion or > derivative of it, under Section 2) in object code or executable form > under the terms of Sections 1 and 2 above provided that you accompany > it with the complete corresponding machine-readable source code, which > must be distributed under the terms of Sections 1 and 2 above on a > medium customarily used for software interchange. > > If distribution of object code is made by offering access to copy > from a designated place, then offering equivalent access to copy the > source code from the same place satisfies the requirement to > distribute the source code, even though third parties are not > compelled to copy the source along with the object code. > > 5. A program that contains no derivative of any portion of the > Library, but is designed to work with the Library by being compiled or > linked with it, is called a "work that uses the Library". Such a > work, in isolation, is not a derivative work of the Library, and > therefore falls outside the scope of this License. > > However, linking a "work that uses the Library" with the Library > creates an executable that is a derivative of the Library (because it > contains portions of the Library), rather than a "work that uses the > library". The executable is therefore covered by this License. > Section 6 states terms for distribution of such executables. > > When a "work that uses the Library" uses material from a header file > that is part of the Library, the object code for the work may be a > derivative work of the Library even though the source code is not. > Whether this is true is especially significant if the work can be > linked without the Library, or if the work is itself a library. The > threshold for this to be true is not precisely defined by law. > > If such an object file uses only numerical parameters, data > structure layouts and accessors, and small macros and small inline > functions (ten lines or less in length), then the use of the object > file is unrestricted, regardless of whether it is legally a derivative > work. (Executables containing this object code plus portions of the > Library will still fall under Section 6.) > > Otherwise, if the work is a derivative of the Library, you may > distribute the object code for the work under the terms of Section 6. > Any executables containing that work also fall under Section 6, > whether or not they are linked directly with the Library itself. > > 6. As an exception to the Sections above, you may also combine or > link a "work that uses the Library" with the Library to produce a > work containing portions of the Library, and distribute that work > under terms of your choice, provided that the terms permit > modification of the work for the customer's own use and reverse > engineering for debugging such modifications. > > You must give prominent notice with each copy of the work that the > Library is used in it and that the Library and its use are covered by > this License. You must supply a copy of this License. If the work > during execution displays copyright notices, you must include the > copyright notice for the Library among them, as well as a reference > directing the user to the copy of this License. Also, you must do one > of these things: > > a) Accompany the work with the complete corresponding > machine-readable source code for the Library including whatever > changes were used in the work (which must be distributed under > Sections 1 and 2 above); and, if the work is an executable linked > with the Library, with the complete machine-readable "work that > uses the Library", as object code and/or source code, so that the > user can modify the Library and then relink to produce a modified > executable containing the modified Library. (It is understood > that the user who changes the contents of definitions files in the > Library will not necessarily be able to recompile the application > to use the modified definitions.) > > b) Use a suitable shared library mechanism for linking with the > Library. A suitable mechanism is one that (1) uses at run time a > copy of the library already present on the user's computer system, > rather than copying library functions into the executable, and (2) > will operate properly with a modified version of the library, if > the user installs one, as long as the modified version is > interface-compatible with the version that the work was made with. > > c) Accompany the work with a written offer, valid for at > least three years, to give the same user the materials > specified in Subsection 6a, above, for a charge no more > than the cost of performing this distribution. > > d) If distribution of the work is made by offering access to copy > from a designated place, offer equivalent access to copy the above > specified materials from the same place. > > e) Verify that the user has already received a copy of these > materials or that you have already sent this user a copy. > > For an executable, the required form of the "work that uses the > Library" must include any data and utility programs needed for > reproducing the executable from it. However, as a special exception, > the materials to be distributed need not include anything that is > normally distributed (in either source or binary form) with the major > components (compiler, kernel, and so on) of the operating system on > which the executable runs, unless that component itself accompanies > the executable. > > It may happen that this requirement contradicts the license > restrictions of other proprietary libraries that do not normally > accompany the operating system. Such a contradiction means you cannot > use both them and the Library together in an executable that you > distribute. > > 7. You may place library facilities that are a work based on the > Library side-by-side in a single library together with other library > facilities not covered by this License, and distribute such a combined > library, provided that the separate distribution of the work based on > the Library and of the other library facilities is otherwise > permitted, and provided that you do these two things: > > a) Accompany the combined library with a copy of the same work > based on the Library, uncombined with any other library > facilities. This must be distributed under the terms of the > Sections above. > > b) Give prominent notice with the combined library of the fact > that part of it is a work based on the Library, and explaining > where to find the accompanying uncombined form of the same work. > > 8. You may not copy, modify, sublicense, link with, or distribute > the Library except as expressly provided under this License. Any > attempt otherwise to copy, modify, sublicense, link with, or > distribute the Library is void, and will automatically terminate your > rights under this License. However, parties who have received copies, > or rights, from you under this License will not have their licenses > terminated so long as such parties remain in full compliance. > > 9. You are not required to accept this License, since you have not > signed it. However, nothing else grants you permission to modify or > distribute the Library or its derivative works. These actions are > prohibited by law if you do not accept this License. Therefore, by > modifying or distributing the Library (or any work based on the > Library), you indicate your acceptance of this License to do so, and > all its terms and conditions for copying, distributing or modifying > the Library or works based on it. > > 10. Each time you redistribute the Library (or any work based on the > Library), the recipient automatically receives a license from the > original licensor to copy, distribute, link with or modify the Library > subject to these terms and conditions. You may not impose any further > restrictions on the recipients' exercise of the rights granted herein. > You are not responsible for enforcing compliance by third parties with > this License. > > 11. If, as a consequence of a court judgment or allegation of patent > infringement or for any other reason (not limited to patent issues), > conditions are imposed on you (whether by court order, agreement or > otherwise) that contradict the conditions of this License, they do not > excuse you from the conditions of this License. If you cannot > distribute so as to satisfy simultaneously your obligations under this > License and any other pertinent obligations, then as a consequence you > may not distribute the Library at all. For example, if a patent > license would not permit royalty-free redistribution of the Library by > all those who receive copies directly or indirectly through you, then > the only way you could satisfy both it and this License would be to > refrain entirely from distribution of the Library. > > If any portion of this section is held invalid or unenforceable under any > particular circumstance, the balance of the section is intended to apply, > and the section as a whole is intended to apply in other circumstances. > > It is not the purpose of this section to induce you to infringe any > patents or other property right claims or to contest validity of any > such claims; this section has the sole purpose of protecting the > integrity of the free software distribution system which is > implemented by public license practices. Many people have made > generous contributions to the wide range of software distributed > through that system in reliance on consistent application of that > system; it is up to the author/donor to decide if he or she is willing > to distribute software through any other system and a licensee cannot > impose that choice. > > This section is intended to make thoroughly clear what is believed to > be a consequence of the rest of this License. > > 12. If the distribution and/or use of the Library is restricted in > certain countries either by patents or by copyrighted interfaces, the > original copyright holder who places the Library under this License may add > an explicit geographical distribution limitation excluding those countries, > so that distribution is permitted only in or among countries not thus > excluded. In such case, this License incorporates the limitation as if > written in the body of this License. > > 13. The Free Software Foundation may publish revised and/or new > versions of the Lesser General Public License from time to time. > Such new versions will be similar in spirit to the present version, > but may differ in detail to address new problems or concerns. > > Each version is given a distinguishing version number. If the Library > specifies a version number of this License which applies to it and > "any later version", you have the option of following the terms and > conditions either of that version or of any later version published by > the Free Software Foundation. If the Library does not specify a > license version number, you may choose any version ever published by > the Free Software Foundation. > > 14. If you wish to incorporate parts of the Library into other free > programs whose distribution conditions are incompatible with these, > write to the author to ask for permission. For software which is > copyrighted by the Free Software Foundation, write to the Free > Software Foundation; we sometimes make exceptions for this. Our > decision will be guided by the two goals of preserving the free status > of all derivatives of our free software and of promoting the sharing > and reuse of software generally. > > NO WARRANTY > > 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO > WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. > EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR > OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY > KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE > IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE > LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME > THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. > > 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN > WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY > AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU > FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR > CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE > LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING > RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A > FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF > SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH > DAMAGES. > > END OF TERMS AND CONDITIONS > > How to Apply These Terms to Your New Libraries > > If you develop a new library, and you want it to be of the greatest > possible use to the public, we recommend making it free software that > everyone can redistribute and change. You can do so by permitting > redistribution under these terms (or, alternatively, under the terms of the > ordinary General Public License). > > To apply these terms, attach the following notices to the library. It is > safest to attach them to the start of each source file to most effectively > convey the exclusion of warranty; and each file should have at least the > "copyright" line and a pointer to where the full notice is found. > > > Copyright (C) > > This library is free software; you can redistribute it and/or > modify it under the terms of the GNU Lesser General Public > License as published by the Free Software Foundation; either > version 2.1 of the License, or (at your option) any later version. > > This library is distributed in the hope that it will be useful, > but WITHOUT ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > Lesser General Public License for more details. > > You should have received a copy of the GNU Lesser General Public > License along with this library; if not, write to the Free Software > Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > > Also add information on how to contact you by electronic and paper mail. > > You should also get your employer (if you work as a programmer) or your > school, if any, to sign a "copyright disclaimer" for the library, if > necessary. Here is a sample; alter the names: > > Yoyodyne, Inc., hereby disclaims all copyright interest in the > library `Frob' (a library for tweaking knobs) written by James Random Hacker. > > , 1 April 1990 > Ty Coon, President of Vice > > That's all there is to it! > ------------------------ end of proposed license ------------------ > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From gjhanna at gmail.com Sun Mar 11 14:21:17 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Mon, 12 Mar 2007 09:21:17 +1300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hi Pavel, We are using RXTX under VMWare server in production, quite satisfactorily. We're using Red Hat Enterprise Server 4, and ... Whatever the "enterprise" VMWare product is. Regards, Greg H > Subject: [Rxtx] RXTX under VMWare server > To: rxtx at qbang.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. [ ... snip ... ] -- Pavel Parkhomenko -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070311/4cebb6f9/attachment-0002.html From gergg at cox.net Sun Mar 11 23:39:19 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 12 Mar 2007 00:39:19 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: <45F4E787.6050502@cox.net> Trent Jarvi wrote: > I can start going through the method interfaces later this week and giving > feedback. I would suggest that the JSR should not be too generic in > nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel > drivers that intend to look like EIA232 ports at the kernel driver level. > > some ideas: > > EIA232PortInterface > TermiosInterface > SerialPortInterface > > Something that differentiates this from thing like USB, I2C, ... which > should not have to deal with legacy serial claiming to be the comm api. I'm going to throw out a suggestion, which I am mostly serious about. What would happen if we took the appropriate bits of the J2ME connector API, and just used that as the new COMM API so that finally JSE and JME had a common foundation for these kinds of things? Gregg Wonderly From ra85551 at gmail.com Mon Mar 12 09:08:37 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Mon, 12 Mar 2007 18:08:37 +0300 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Should any application use the modem, HyperTerminal won't be able to talk to the modem. But it actually can send and receive AT comands, while my application cannot :-( > Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Thansk for the reference. I examined that example and found that there's no significant differences between my read/write implementation and that one, except that SimpleSnuV1 listens for serialEvent's, but not for sake of data retrieval, just for printing them out - I don't know why ;-) > Note that modems could care less what OS is on top. If you are trying to > match new lines to the OS and sending it to the mode for AT commands, > thats probably a mistake. I do send strings to serial port, not to OS, and do try to get answers back. If it is the mistake, what's the right way? > Also it would not hurt to print out the > individual bytes that you are sending to make sure they did not get > mangled along the path. Yeah, I am printing these bytes before doing write, but it means that I only see what I intend to write. How can I ensure that these bytes have gone out of the box and reached my modem? BTW, I found that my send/receive method is complex enough, so I've rewritten it. Please, see the following code and point any mistakes, because I don't know where can they remain yet. private static final int LARGE_TIMEOUT = 15000; private static final int SMALL_TIMEOUT = 500; ... private String sendATCommand(String command, String waitFor, boolean isRegex, boolean isAddCRLF) throws BeaconConnectException { byte[] buffer = new byte[512]; int offset; String result = ""; try { if (waitFor != null) { serialPort.enableReceiveTimeout(LARGE_TIMEOUT); } else { serialPort.enableReceiveTimeout(SMALL_TIMEOUT); } if (command != null) { OutputStream serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } offset = 0; InputStream serialInput = serialPort.getInputStream(); while (serialInput.available() != -1) { int bytesRead = serialInput.read(buffer, offset, buffer.length - offset); if (bytesRead == 0) { break; } offset += bytesRead; result = new String(buffer, 0, offset).trim(); if (waitFor != null) { System.out.println(result); if (isRegex && result.matches(waitFor) || result.contains(waitFor)) { break; } } } } catch (UnsupportedCommOperationException e) { throw new MyException("unsupported operation"); } catch (IOException e) { throw new MytException("serial I/O error"); } return result; } -- Pavel Parkhomenko From clayno at hotpop.com Thu Mar 15 02:47:34 2007 From: clayno at hotpop.com (Christopher Layno) Date: Thu, 15 Mar 2007 16:47:34 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi, we're using the latest release of rxtx (2.1-7r2) for our system that has two applications using the library. one application sends requests to the modem while the other simply checks the modem status. we deployed our system on a pentium machine with red hat linux 9.0 installed. now the problem arises when these two applications try to access the same modem at the same time. one of them will eventually have to throw the PortInUseException as shown below: 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException gnu.io.PortInUseException: root PID = 743 Program = java root PID = 743 Program = java root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) this was expected. what we didn't expect though was that if we repeat the scenario 5 times, always 5 times, the application would also throw a VM error: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4473CD21 Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so Current Java thread: at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) - locked <0x44cfd4c8> (a gnu.io.CommPortIdentifier) at ************ at ************ - locked <0x4476a468> (a **********) at ************ at ************ at ************ at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java :261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages( TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run( TCPTransport.java:701) at java.lang.Thread.run(Thread.java:534) note: i replaced some sensitive data with asterisks our team has looked everywhere on the internet, including your mail archives, for a solution to this problem but to no avail. i really hope you could help us out on this one. thanks in advance! best regards, chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070315/1936460a/attachment-0002.html From tjarvi at qbang.org Fri Mar 16 04:30:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 04:30:25 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: On Thu, 15 Mar 2007, Christopher Layno wrote: > hi, > > we're using the latest release of rxtx (2.1-7r2) for our system that has two > applications using the library. one application sends requests to the modem > while the other simply checks the modem status. we deployed our system on a > pentium machine with red hat linux 9.0 installed. > > now the problem arises when these two applications try to access the same > modem at the same time. one of them will eventually have to throw the > PortInUseException as shown below: > > 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException > gnu.io.PortInUseException: root PID = 743 Program = java root PID = > 743 Program = java root PID = 743 Program = ??? root PID = 743 Program > = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root > PID = 743 Program = ??? root PID = 743 Program = ??? > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > > this was expected. what we didn't expect though was that if we repeat the > scenario 5 times, always 5 times, the application would also throw a VM > error: > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x4473CD21 > Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 > Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so > > Current Java thread: > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) Hi Chris The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. The code is originally by Werner Almesberger. He gave us permission to use it in rxtx. You might look at what has changed since 1998 in his fuser application. Or you can just do like other OSs and do the following in fuserImp.c JNIEXPORT jstring JNICALL Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv *env, jobject obj, jstring arg) { return (*env)->NewStringUTF(env, "Unknown Application"); } It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. -- Trent Jarvi tjarvi at qang.org From Adrien.TOS at ingenico.com Fri Mar 16 05:11:12 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Fri, 16 Mar 2007 12:11:12 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903CBC312@frsnprexc1.usr.ingenico.loc> Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070316/972ab214/attachment-0002.html From joachim at buechse.de Fri Mar 16 05:13:24 2007 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 16 Mar 2007 12:13:24 +0100 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. From tjarvi at qbang.org Fri Mar 16 16:36:29 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 16:36:29 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Fri Mar 16 16:02:23 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 16 Mar 2007 18:02:23 -0400 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Not all platforms are Unix based. Also mixing native library usage and command-line calls is not an elegant solution, IMHO. One or the other, but not both. Andre On 16-Mar-07, at 07:13 , Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is > trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We >> only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From clayno at hotpop.com Sun Mar 18 22:17:28 2007 From: clayno at hotpop.com (Christopher Layno) Date: Mon, 19 Mar 2007 12:17:28 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi everyone, thank you so much for your replies. they were really helpful. anyway, before i sent the email, my team was already implementing a temporary solution by using joachim's suggestion. we invoked a lsof command from our java code although i share the same concern with trent and andre-john about portability issues. that's why i said it's just temporary. my superiors have yet to approve our bug fix. so my question now is this: is recompiling the rxtx source code the only way to solve this problem? because if it's the only solution, then i think my superiors would rather have a new release from the rxtx community itself that fixes this bug(?) rather than have my team recompile the source code. best regards, chris Trent Jarvi wrote: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. ... It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070318/237463b2/attachment-0002.html From tjarvi at qbang.org Mon Mar 19 16:20:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Mar 2007 16:20:52 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: Hi Chris I can compile a new version after the 21st if you do not feel comfortable doing so. Please send me an email reminder off-line then. On Mon, 19 Mar 2007, Christopher Layno wrote: > hi everyone, > > thank you so much for your replies. they were really helpful. > > anyway, before i sent the email, my team was already implementing a > temporary solution by using joachim's suggestion. > we invoked a lsof command from our java code although i share the same > concern with trent and andre-john about > portability issues. that's why i said it's just temporary. my superiors have > yet to approve our bug fix. > > so my question now is this: is recompiling the rxtx source code the only way > to solve this problem? because if it's the only > solution, then i think my superiors would rather have a new release from the > rxtx community itself that fixes this bug(?) > rather than have my team recompile the source code. > > best regards, > > chris > > Trent Jarvi wrote: > > Hi Joachim > > It would be nice to have that functionality but calling the program > introduces too many issues imho. Explaining to someone why rxtx invoked a > rogue lsof does not sound very interesting. > > On Fri, 16 Mar 2007, Joachim Buechse wrote: > > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: > > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. > > _______________________________________________ > Rxtx mailing list > Rxtx 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 Eric.Arseneau at sun.com Tue Mar 20 11:47:33 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Tue, 20 Mar 2007 10:47:33 -0700 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 Message-ID: <46001E35.9040608@sun.com> Anyone have any experience with RXTX working with JDK 6 on other platforms ? From mm at UDel.Edu Tue Mar 20 12:18:29 2007 From: mm at UDel.Edu (Mike Markowski) Date: Tue, 20 Mar 2007 14:18:29 -0400 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 In-Reply-To: <46001E35.9040608@sun.com> References: <46001E35.9040608@sun.com> Message-ID: <46002575.4000306@udel.edu> Eric Arseneau wrote: > Anyone have any experience with RXTX working with JDK 6 on other platforms ? I'm using 32 bit intel, gentoo linux, jdk6 with no problems. My applications only use a serial port, though, nothing on the parallel port. Mike From falko.guderian at gmx.de Wed Mar 21 08:17:35 2007 From: falko.guderian at gmx.de (Falko Guderian) Date: Wed, 21 Mar 2007 15:17:35 +0100 Subject: [Rxtx] RXTX binaries for SH4 Message-ID: <46013E7F.40102@gmx.de> Dear developers, I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no possiblities to compile the source code. Better, I'm not able to do this at the moment. Can you provide me with rxtxSerial.dll (SH4) in the rxtx-2.1-8-testing version? (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) The reason for the testing version is I need custom baud rates. Thanks for help. Kind regards, Falko Guderian From tjarvi at qbang.org Wed Mar 21 21:38:37 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Mar 2007 21:38:37 -0600 (MDT) Subject: [Rxtx] RXTX binaries for SH4 In-Reply-To: <46013E7F.40102@gmx.de> References: <46013E7F.40102@gmx.de> Message-ID: On Wed, 21 Mar 2007, Falko Guderian wrote: > Dear developers, > > I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no > possiblities to compile the source code. Better, I'm not able to do this > at the moment. Can you provide me with rxtxSerial.dll (SH4) in the > rxtx-2.1-8-testing version? > (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) > > The reason for the testing version is I need custom baud rates. > > Thanks for help. > Hi Falko WinCE binary format is not supported by gcc. That makes compiling limited to those familiar with the WinCE tools. I hope someone is able to provide them for you but it is not likely. WinCE has been compiled by others in the past but rxtx.org builds have never included WinCE. There is some information with the source concerning WinCE builds if you decide to do it. We can share your results too if you like. The source in the WinCE has never been updated for the custom baud rate. That would need changes from the main source I presume. If you look at the source, you will note that Michal Hobot created a mini fork in the source to handle wince but it has not been updated for 3 years. -- Trent Jarvi tjarvi at qbang.org From Adrien.TOS at ingenico.com Thu Mar 22 07:08:55 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Thu, 22 Mar 2007 14:08:55 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Hi everybody, Do you have any comments on this issue? Thanks! AT ________________________________ De : Adrien TOS Envoy? : vendredi 16 mars 2007 12:11 ? : 'rxtx at qbang.org' Cc : Adrien TOS Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070322/2306c538/attachment-0002.html From jeremy.reeve at zen.co.uk Mon Mar 19 07:36:04 2007 From: jeremy.reeve at zen.co.uk (Jeremy S. Reeve) Date: Mon, 19 Mar 2007 13:36:04 +0000 Subject: [Rxtx] rxtx failing to compile on Fedora Core 6 Message-ID: <1174311364.21865.6.camel@d9thc> When trying to compile latest source : rxtx-2.1-7r2 I get the following when running configure: ---------------- checking os.version 2.6.18-1.2200.fc5smp WARNING: configure is having a hard time determining which directory contains the file jni_md.h. Edit Makefile and fix the variable JAVANATINC to point to the correct directory. The following options are available: /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/ /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/linux/ If there are more than one option available the first was selected. WARNING: Kernel include files do not match the current kernel configure: creating ./config.status ------------------------ which seems OK checking the resultant Makefile but when attempting to build with gmake install I get the following output : ---------------------- 34 problems (34 warnings)/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/javah -classpath .:/home/jsr/rxtxsrc/rxtx-2.1-7r2:/home/jsr/rxtxsrc/rxtx-2.1-7r2/src:/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/ext/RXTXcomm.jar -d i686-pc-linux-gnu -jni `(for i in CommDriver CommPortEnumerator CommPortIdentifier CommPort CommPortOwnershipListener Configure I2C I2CPortEvent I2CPortEventListener I2CPort LPRPort NoSuchPortException ParallelPortEvent ParallelPortEventListener ParallelPort PortInUseException Raw RawPortEvent RawPortEventListener RawPort RS485 RS485PortEvent RS485PortEventListener RS485Port RXTXCommDriver RXTXPort RXTXVersion SerialPortEvent SerialPortEventListener SerialPort UnsupportedCommOperationException UnSupportedLoggerException Zystem;do \ if grep > /dev/null native.* \( /home/jsr/rxtxsrc/rxtx-2.1-7r2/./src/$i.java; then \ echo gnu.io.$i; \ fi; \ done)` i686-pc-linux-gnu/gnu_io_CommPortIdentifier.h: No such file or directory make: *** [/home/jsr/rxtxsrc/rxtx-2.1-7r2/gnu/io/CommDriver.class] Error 1 ------------------------ Any ideas or pointers? Regards, Jeremy From tjarvi at qbang.org Sat Mar 24 08:12:54 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 Mar 2007 08:12:54 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > From Adrien.TOS at ingenico.com Sat Mar 24 11:53:22 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Sat, 24 Mar 2007 18:53:22 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> I do not have the threshold setting enabled, I have explicitely disabled it with: port_.disableReceiveThreshold(); I have also run the same tests with the threshold setting enabled, but they also fail in the same way as described below. So it seems there is a problem with timeout handling on Win32? ________________________________ From: rxtx-bounces at qbang.org on behalf of Trent Jarvi Sent: Sat 3/24/2007 3:12 PM To: RXTX Developers and Users Subject: Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 8312 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20070324/f9e39c9b/attachment-0002.bin From greg.johnson at manchester.ac.uk Sun Mar 25 13:41:36 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Sun, 25 Mar 2007 21:41:36 +0200 Subject: [Rxtx] Mac intel weirdness Message-ID: Hi folks, I'm trying to get rxtx to work on my macbook pro with a USB-serial dongle on it. I am using the 2.1-8 code from the CVS (though it seems to report itself as 2.1-7: makes it difficult to prove to oneself that the changes have 'taken'! - line 4210 in SerialImp.c, line 40 in RXTXVersion.java) I am trying the 2.1-8 because of horrible lock problems in 2.1-7. However, the serialport closure code seems to be broken - it won't close because it believes the (previously opened!) port doesn't exist. Here is what I'm trying: 0. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "false" 1. Open a port Serialport serialport = (SerialPort) commportidentifier.open ("test",100); 2. Talk to a device ... 3. Close port serialport.close(); 4. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "true" - why is this? 5. Try to reopen port Serialport serialport2 = (SerialPort) commportidentifier.open("test", 100); throws PortInUseException. I've dug around a bit in the source, and it seems the SerialPort.close () should call the CommPortIdentifier.internalClosePort() (line 67 of CommPort.java). However, I crash out with the NoSuchPortException when getPortIdentifier is called. Which seems quite weird to me, seeing as it is called on this - which was create just beforehand. Does anyone know how to fix this? Cheers, greg From knute at frazmtn.com Sat Mar 24 10:32:38 2007 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 24 Mar 2007 09:32:38 -0700 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc>, Message-ID: <4604F036.17833.135298@knute.frazmtn.com> > >The behavior of timeout depends upon the setting of the threshold. Do you >have the threshold setting? > This is the same bug I reported last fall. There was a fellow that sent me an email asking if it had been fixed. I told him I didn't think so. He got somebody to write a fix for him but I have not been able to contact him again for the actual changes. The inaccurate timeout and the failure of blocking when no timeouts are set is a serious bug in my humble opinion and renders the software unusable for my applications. I'd really like to have an alternative to the Sun comm api but there just isn't one that I know of. -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Mar 26 16:17:00 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 26 Mar 2007 16:17:00 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> Message-ID: >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. From ra85551 at gmail.com Tue Mar 27 10:18:36 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Tue, 27 Mar 2007 20:18:36 +0400 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Ultimately I found a solution. At first, that wasn't actually the VMWare + WinXP + RXTX issue, that was WinXP + RXTX issue. But on pure XP it sometimes workes, sometimes not, while under VMWare I had never seen my snippet working at all. SimpleSnuV1.java would not help me, because there is only one line I missed, and SimpleSnuV1.java also doesn't contain it! It is as follows: serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_OUT | SerialPort.FLOWCONTROL_RTSCTS_IN); Thank you for your attention. -- Pavel Parkhomenko From griff at op.pl Wed Mar 28 01:28:19 2007 From: griff at op.pl (griff@op.pl) Date: Wed, 28 Mar 2007 09:28:19 +0200 Subject: [Rxtx] No blocking read on Windows. Message-ID: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/5d07d571/attachment-0002.html -------------- next part -------------- Hi, I have problem that InputStram.read() (SerialPort)?returns -1 instead blocking and waiting for data. I found that this problem was ?known in 2005 : ? >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > >> Hi Trent >> >> Thanks for the fast response. >> Here's a Q&D test program for the blocking read on windows that just >> attempts to read one byte, and prints the resulting byte. On my system it >> returns -1, where I expect that it keeps waiting for data. >> >This isn't happening on Linux so the bug is in src/termios.c.? I'll have >something this weekend to fix that. I'm using RXTX 2.1.7r2 and the problem still is here. Im using Windows XP and java 1.5 disableReciveTimeout() and disableReciveTreshhold() dont help. ? best regards ? Piotr Zielniok From Adrien.TOS at ingenico.com Wed Mar 28 01:40:46 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Wed, 28 Mar 2007 09:40:46 +0200 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903E88880@frsnprexc1.usr.ingenico.loc> Looking at the code, it seems there is no support for infinite timeout? And maybe the count++ < 20 condition is breaking out of the loop too early? The only condition to break out of the loop should either be the timeout has expired or the number of requested bytes has been received. -----Message d'origine----- De : rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] De la part de Trent Jarvi Envoy? : mardi 27 mars 2007 00:17 ? : RXTX Developers and Users Objet : Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From j.kenneth.gentle at acm.org Wed Mar 28 06:44:15 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 28 Mar 2007 08:44:15 -0400 Subject: [Rxtx] No blocking read on Windows. In-Reply-To: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> References: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> Message-ID: <200703281844.l2SIiITW028614@qbang.org> Just another "ME TOO!" - I'm seeing this problem on Windows XP, jre for windows XP/Embedded. I cranked receiveTimeout up to Integer.MAX_INT, but it doesn't seem to wait that long At 03:28 2007-03-28, you wrote: >Hi, >I have problem that InputStram.read() (SerialPort) returns -1 >instead blocking and waiting for data. I found that this problem >was known in 2005 : > > >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > > > >> Hi Trent > >> > >> Thanks for the fast response. > >> Here's a Q&D test program for the blocking read on windows that just > >> attempts to read one byte, and prints the resulting byte. On my system it > >> returns -1, where I expect that it keeps waiting for data. > >> > > >This isn't happening on Linux so the bug is in src/termios.c. I'll have > >something this weekend to fix that. > >I'm using RXTX 2.1.7r2 and the problem still is here. >Im using Windows XP and java 1.5 >disableReciveTimeout() and disableReciveTreshhold() dont help. > >best regards > >Piotr Zielniok > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From greg.johnson at manchester.ac.uk Wed Mar 28 14:43:29 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Wed, 28 Mar 2007 22:43:29 +0200 Subject: [Rxtx] Cannot close and reopen serial port Message-ID: <377F9765-7A9D-4CE9-9176-FFB63A2594F0@manchester.ac.uk> Dear all, It appears I cannot close a port properly: SerialPort serialport = portid.open("myprog",100); // do some stuff, all works fine serialport.close(); // all seems fine but... SerialPort sp2 = portid.open("myprog",100); throws PortInUseException. And when I dig into the rxtx code, I find in CommPort.java, in close(): CommPortIdentifier cp = CommPortIdentifier.getPortIdentifier(this); (line 64 or there abouts) but this throws a NoSuchPortException which is caught but ignored (line 74ish). Can anyone suggest how this could happen: a port that was valid, opened, and used, throws a NSPE when it comes to closing it? I'm pulling my (remaining) hair out over this one! Cheers, greg PS And thanks for RXTX - it's great to have! PPS (21.-7. winxp/osx both, java 1.5) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/c28852fc/attachment-0002.html From rxtx at vrijheidslaan.net Fri Mar 30 16:52:50 2007 From: rxtx at vrijheidslaan.net (Rob) Date: Fri, 30 Mar 2007 22:52:50 -0000 Subject: [Rxtx] Cvs Question Message-ID: <61896.80.126.150.87.1175295162.squirrel@webmail.provalue.nl> Hi There, Im trying to get the latest version to work on mac osx. Problem is that i can't checkout version 2.1.8. Probably my fault but can some one please give me the alternative commands for: [user at myhost]$ export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot [user at myhost]$ cvs login Thanx, Rob From ra85551 at gmail.com Thu Mar 1 03:47:06 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Thu, 1 Mar 2007 13:47:06 +0300 Subject: [Rxtx] enableReceiveTimeout() issue Message-ID: Hello, world! I found a limitation of 16300 ms for CommPort's enableReceiveTimeout() method, while in original javax.comm docs there are no any references to that. Is that a bug or feature? I actually need longer timeouts sometimees. -- Pavel Parkhomenko From lyon at docjava.com Thu Mar 1 07:54:17 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 01 Mar 2007 09:54:17 -0500 Subject: [Rxtx] parametric singleton design pattern In-Reply-To: References: <22d55aea0702081207q5e7f6785l352d498d6f5f9fb1@mail.gmail.com> <22d55aea0702100034o3bcf42f3j1d1a6257029a67b0@mail.gmail.com> Message-ID: Hi All, I have been thinking about the use of a design pattern to cache resources that are consumed by processes. Toward that end, I have arrived at a parametric singleton design pattern, which I mentioned on this list some time ago. The idea has been published at: http://www.jot.fm/issues/issue_2007_03/column2 I can't help but think that there should be an API available for dealing with the tracking of serial port usage. Perhaps it is a kind of resource manager called the: SerialPortManager basic prototypes already exist in this vain. See, for example: http://www.ce.rit.edu/research/projects/2005_fall/rt_poolsystem/doc/PoolMon/SerialPortManager.html http://www.eventhelix.com/RealtimeMantra/PatternCatalog/serial_port_design_pattern.htm And others shown by a google search on "SerialPortManager" Cheers! - Doug From Eric.Arseneau at sun.com Thu Mar 1 10:15:03 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:15:03 -0800 Subject: [Rxtx] Any known Java 6 issues with RXTX 2.1-7r2 ? Message-ID: <45E70A17.1060206@sun.com> I just did a test on a recent build of Solaris 11 x86 and it seems that I can connect to my serial device fine when Java 5 is the default, but when Java 6 is the default, no go. Any information ? From Eric.Arseneau at sun.com Thu Mar 1 10:19:58 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:19:58 -0800 Subject: [Rxtx] Mac OS X and missing data Message-ID: <45E70B3E.7040908@sun.com> We have a device which is USB based but presents itself as a serial port to a machine. On my MacBook Pro I can get excellent throughput if I get my device to send data as quickly as possible. On the desktop side, if I do an type of disk IO to log the data I get, I end up with some missing data at some point. I hooked up a USB analyzer and did confirm that all the data is sent as expected to the desktop from the device. I found a work around for this, buffer the data in memory and only write the data out when I've received it all. However, when the same code and same device is attempted on a co-workers MacBook Pro (same hardware specs), I get errors and must slow down dramatically the device side's sending of data. Any ideas/recommendations on what I can do to get rid of this error ? From what I can tell, it seems that RXTX is not able to wake up to the interrupts coming in indicating data is ready, quickly enough, is there anything I can do ? From chinkaiw at hotmail.com Fri Mar 2 00:57:43 2007 From: chinkaiw at hotmail.com (Wang Chinkai) Date: Fri, 02 Mar 2007 07:57:43 +0000 Subject: [Rxtx] dynamic detect rs232 port Message-ID: Hi all I have a question about detecting rs232 port dynamicly. I have to aceess some port and detect rs232 port at the same time. Some usb device simulates rs232 port , and I can not know what the port name it gets until it connects,so I have to detect it dynamic,but I have to access another rs232 device at the same time. I found a problem. If I use CommPortIdentifier.getPortIdentifiers() to get new port list , and the other rs232 access function will not close port correctly. So , How can I solve it . Thanks. _________________________________________________________________ ?? 2GB ???? Windows Live Mail ????????????? http://ideas.live.com/programpage.aspx?versionid=5d21c51a-b161-4314-9b0e-4911fb2b2e6d From eu259473 at tele2.it Fri Mar 2 06:16:40 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 02 Mar 2007 14:16:40 +0100 Subject: [Rxtx] rxtx on HP tru 64 unix Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070302/706c7a70/attachment-0003.html From tjarvi at qbang.org Fri Mar 2 08:39:33 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 08:39:33 -0700 (MST) Subject: [Rxtx] rxtx on HP tru 64 unix In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, "Giuseppe Marchese" wrote: > Hi > > I try to install rxtx on hp tru 64 but make fails, > There are somebody that do the same and work. > > > Sorry for may english! > > Hi Giuseppe Could you provide a log of the failure? script ./configure make # use gnu make exit The information will be in the typescript created. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 2 19:56:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 19:56:52 -0700 (MST) Subject: [Rxtx] dynamic detect rs232 port In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, Wang Chinkai wrote: > Hi all > > I have a question about detecting rs232 port dynamicly. > > I have to aceess some port and detect rs232 port at the same time. > Some usb device simulates rs232 port , and I can not know > what the port name it gets until it connects,so I have to detect it > dynamic,but I have to access > another rs232 device at the same time. > > I found a problem. Hi Wang This is a known problem. The code is braindead there. In fact there needs to be events even in a rudamentary way when you add a usb dongle. I'm burried in tasks not far from rxtx but not in rxtx. I can't get to the problem but we would accept patches if you dig into it. [I'm getting to the license question earlier too; I don't have another 10%] -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Fri Mar 2 23:19:01 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 01:19:01 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Hi, Under ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable USB -> serial converter(using virtual com port drivers), with using example code pretty much straight out of http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port opens fine, enumerations all work, etc. My application calls for a large amount of data to be transferred in a short amount of time at 2,000,000 baud. My hardware sends approximately 15,232 bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL converter work fine, and the application works using C++. In C++, I do a hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); to open the port, and a boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); to read the port. The variable buffer fills with the 15238 bytes, and returns. If I do a resultz = is.read(cbuf,0,15238); in java with RXTX where is = new BufferedReader(new InputStreamReader(port.getInputStream())); and where resultz is an int, and cbuf is a char [] cbuf, resultz gets EXACTLY 3968 bytes the first time called. If I call it multiple times, I get roughly 11k total(less than what is sent), never more than the 3968 bytes per is.read() call. My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 bytes. I've played with inputbuffersize, receive threshold, receivetimeout, and so on. The FTDI virtual com port drivers that I'm using are rock solid, and have had zero problems with them using a variety of applications, some of my own, some professionally written, etc. No flow control is used anyplace, no RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. No exceptions are being thrown. What am I doing wrong, and what I can adjust to receive the full 15k bytes in one single read? Thanks! Keith From Eric.Arseneau at sun.com Fri Mar 2 23:32:07 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Fri, 02 Mar 2007 22:32:07 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <45E91667.20501@sun.com> This is the same type of thing that is happening to me on Mac OS X and does not seem to behave the same on different machines. I posted a day or two ago on this with subject "Mac OS X and missing data". Would love to hear if there is a solution to this :) From tjarvi at qbang.org Sat Mar 3 10:54:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 10:54:17 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > Hi, > > Under > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable > USB -> serial converter(using virtual com port drivers), with using example > code pretty much straight out of > http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port > opens fine, enumerations all work, etc. > > My application calls for a large amount of data to be transferred in a short > amount of time at 2,000,000 baud. My hardware sends approximately 15,232 > bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL > converter work fine, and the application works using C++. > > In C++, I do a > > hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, > OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); > > to open the port, and a > > boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); > > to read the port. > > The variable buffer fills with the 15238 bytes, and returns. > > If I do a > > resultz = is.read(cbuf,0,15238); in java with RXTX > > where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > > and where resultz is an int, and cbuf is a char [] cbuf, resultz gets > EXACTLY 3968 bytes the first time called. If I call it multiple times, I get > roughly 11k total(less than what is sent), never more than the 3968 bytes > per is.read() call. > > My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 > bytes. > > I've played with inputbuffersize, receive threshold, receivetimeout, and so > on. The FTDI virtual com port drivers that I'm using are rock solid, and > have had zero problems with them using a variety of applications, some of my > own, some professionally written, etc. No flow control is used anyplace, no > RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. > > No exceptions are being thrown. > > What am I doing wrong, and what I can adjust to receive the full 15k bytes > in one single read? > > Thanks! > Hi Keith I would expect a 20 meg application is going to have different behavior with the OS than a smaller application with respect to the kernel memory managment, schedualing, ... Something subtle could be causing problems. With respect to the recieve timeout and threshold, if you set the timeout to zero and the threshold to the size of data you expect, read should not return until it get that data. You may try with a stand alone application that tests just that with the C/C++ API. If the read is returning with less data when tested for short reads, you have found a bug in the device driver more than likely. The USB dongle vendor would probably be interested in knowing about this. As mentioned, these devices are getting very good; almost bug free. I suspect you found a bug though if you did use the threshold and timeout properly. The missing data is typical when not using flow control. When the OS buffering fills, the hardware will start dropping bytes. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:38:52 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:38:52 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> update: I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now instead of 3968. This makes sense. 128 bytes of overhead + 3968 bytes of data = 4096 transfer size 32 bytes of overhead + 992 bytes of data = 1024 transfer size. 1/4 the data = 1/4 the overhead. I rearranged my reading like so: resultz = is.read(cbuf,0,3968); resultz = is.read(cbuf,3968,3968); resultz = is.read(cbuf,7936,3968); while (!(is.ready())); // wait for ready resultz = is.read(cbuf,11904,3334); and this grabs 15,238 bytes total. BUT, I still have the quandry of the screwed up multi-bytes. I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. Approx 8% of the data. The bad bytes always seem to take the flavor of 0x2018, 0x2019, x2022, x2030, x201d. Are these maybe errors and I don't know what they enumerate to? I still can't believe some other layer isn't handling putting those bytes together all in one stream for me. Thanks Keith ----- Original Message ----- From: "Keith" To: "Bob Jacobsen" ; "RXTX Developers and Users" Sent: Saturday, March 03, 2007 11:26 AM Subject: Re: [Rxtx] is.read() only returning 3968 bytes > Bob, > > > Interesting numerical coincidence is that (max USB transfer) - (what > > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > > needed to transfer that much data. > > I was thinking along the same lines. I don't know USB well, but I do know > that those numbers were close enough to warrant investigating the > relationship between them. > > > I think what you're seeing is the internal buffering of the USB data > > stream. You'll need some form of higher-level buffering to smooth > > that out. > > Shouldn't the InputStreamReader() and BufferedReader() provide this type of > buffering? Isn't that the idea behind those? > > > All hypotheses need to be tested. In this case, a test would be to > > check for missing data. If this idea is right, you'll get _all_ the > > data, but you won't be missing characters. > > I did start looking at the data. -- I'm getting weird results. > > I tried this: > > loopzz = 0; > > for (looptwo = 0; looptwo < 100000; looptwo++) { > while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > > }} > > So I'm reading one character at a time. The good news is that loopzz is > exactly 15238 at the end of the routine, which is perfectly correct. I > picked looptwo value out of thin air. > > The weird results come in terms of the values, the data isn't correct at > least in one case. Look here: > > 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > > This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). > But the 0x89 was replaced by 0x2030. Why the heck would the returned value > be 0x2030?? Why is the returned byte completely out of range? Why the > multibyte return? > > From InputStream in the API: > > read > public abstract int read() > throws IOExceptionReads the next byte of data from the > input stream. The value byte is returned as an int in the range 0 to 255. If > no byte is available because the end of the stream has been reached, the > value -1 is returned. This method blocks until input data is available, the > end of the stream is detected, or an exception is thrown. > Value should be 0-255. > > > In my application time is really critical, reading 1 byte at a time is > probably not going to work. > > Thanks Eric & Bob for looking at this. > > Keith > From tjarvi at qbang.org Sat Mar 3 12:52:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 12:52:27 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > update: > > I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now > instead of 3968. > > This makes sense. > > 128 bytes of overhead + 3968 bytes of data = 4096 transfer size > 32 bytes of overhead + 992 bytes of data = 1024 transfer size. > > 1/4 the data = 1/4 the overhead. > > I rearranged my reading like so: > > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. > Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? > > I still can't believe some other layer isn't handling putting those bytes > together all in one stream for me. > The layer for this in Serial land is flow control. Software and hardware flow control prevent the overruns you observe. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:54:41 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:54:41 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <001a01c75dcd$c8802a70$6600a8c0@jbh757ktruws7g> Trent, Thanks for taking the time to reply. > I would expect a 20 meg application is going to have different behavior > with the OS than a smaller application with respect to the kernel memory > managment, schedualing, ... Something subtle could be causing problems. Well, at least I know the VCP drivers, the OS, etc can handle 2mbps reliably. Without hiccuping or dropping bytes. The C++ code works reliably without flow control. > The missing data is typical when not using flow control. When the OS > buffering fills, the hardware will start dropping bytes. I'm actually not getting MISSING data, I'm getting CORRUPTED data. If you look at my most recent post, I'm getting these bad bytes in place of the correct values: 0x2018, 0x2019, x2022, x2030, x201d. Why would is.read() return values not in the range of 0-255 ? Thanks. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 08:59:14 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 07:59:14 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: At 1:19 AM -0500 3/3/07, Keith wrote: >If I do a > >resultz = is.read(cbuf,0,15238); in java with RXTX > >where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > >and where resultz is an int, and cbuf is a char [] cbuf, resultz gets >EXACTLY 3968 bytes the first time called. If I call it multiple times, I get >roughly 11k total(less than what is sent), never more than the 3968 bytes >per is.read() call. > >My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 >bytes. Interesting numerical coincidence is that (max USB transfer) - (what you get) = 4096-3968 = 128 bytes is (almost) the size of the headers needed to transfer that much data. I think what you're seeing is the internal buffering of the USB data stream. You'll need some form of higher-level buffering to smooth that out. All hypotheses need to be tested. In this case, a test would be to check for missing data. If this idea is right, you'll get _all_ the data, but you won't be missing characters. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 09:26:14 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 11:26:14 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Bob, > Interesting numerical coincidence is that (max USB transfer) - (what > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > needed to transfer that much data. I was thinking along the same lines. I don't know USB well, but I do know that those numbers were close enough to warrant investigating the relationship between them. > I think what you're seeing is the internal buffering of the USB data > stream. You'll need some form of higher-level buffering to smooth > that out. Shouldn't the InputStreamReader() and BufferedReader() provide this type of buffering? Isn't that the idea behind those? > All hypotheses need to be tested. In this case, a test would be to > check for missing data. If this idea is right, you'll get _all_ the > data, but you won't be missing characters. I did start looking at the data. -- I'm getting weird results. I tried this: loopzz = 0; for (looptwo = 0; looptwo < 100000; looptwo++) { while (is.ready()) { cbuf[loopzz] = (char) is.read(); loopzz++; }} So I'm reading one character at a time. The good news is that loopzz is exactly 15238 at the end of the routine, which is perfectly correct. I picked looptwo value out of thin air. The weird results come in terms of the values, the data isn't correct at least in one case. Look here: 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). But the 0x89 was replaced by 0x2030. Why the heck would the returned value be 0x2030?? Why is the returned byte completely out of range? Why the multibyte return? >From InputStream in the API: read public abstract int read() throws IOExceptionReads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown. Value should be 0-255. In my application time is really critical, reading 1 byte at a time is probably not going to work. Thanks Eric & Bob for looking at this. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 14:44:50 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 13:44:50 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: Java's "char" type is Unicode. I think what you're seeing is a bug in the byte -> Unicode translation. 0x2018, 0x2019 are the curly open and close quotes. There used to be (and might still be) bugs in the conversion of these in a couple of libc versions. Some of the ASCII -> ISO and ISO -> ASCII routines were a little over-ambitious with respect to handling the open and close quotes, and tried to convert them to the "curly" form inappropriately. Try _not_ casting it to char. Bob At 11:26 AM -0500 3/3/07, Keith wrote: >Bob, > >> Interesting numerical coincidence is that (max USB transfer) - (what >> you get) = 4096-3968 = 128 bytes is (almost) the size of the headers >> needed to transfer that much data. > >I was thinking along the same lines. I don't know USB well, but I do know >that those numbers were close enough to warrant investigating the >relationship between them. > >> I think what you're seeing is the internal buffering of the USB data >> stream. You'll need some form of higher-level buffering to smooth >> that out. > >Shouldn't the InputStreamReader() and BufferedReader() provide this type of >buffering? Isn't that the idea behind those? > >> All hypotheses need to be tested. In this case, a test would be to >> check for missing data. If this idea is right, you'll get _all_ the >> data, but you won't be missing characters. > >I did start looking at the data. -- I'm getting weird results. > >I tried this: > >loopzz = 0; > >for (looptwo = 0; looptwo < 100000; looptwo++) { >while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > >}} > >So I'm reading one character at a time. The good news is that loopzz is >exactly 15238 at the end of the routine, which is perfectly correct. I >picked looptwo value out of thin air. > >The weird results come in terms of the values, the data isn't correct at >least in one case. Look here: > >0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > >This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). >But the 0x89 was replaced by 0x2030. Why the heck would the returned value >be 0x2030?? Why is the returned byte completely out of range? Why the >multibyte return? > >>From InputStream in the API: > >read >public abstract int read() > throws IOExceptionReads the next byte of data from the >input stream. The value byte is returned as an int in the range 0 to 255. If >no byte is available because the end of the stream has been reached, the >value -1 is returned. This method blocks until input data is available, the >end of the stream is detected, or an exception is thrown. >Value should be 0-255. > > >In my application time is really critical, reading 1 byte at a time is >probably not going to work. > >Thanks Eric & Bob for looking at this. > >Keith > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 15:10:11 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 17:10:11 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Bob said ..... > Java's "char" type is Unicode. I think what you're seeing is a bug > in the byte -> Unicode translation. Bob -- I think you hit the nail on the head. I was just coming to the same realization here. I knew that something funny was going on because the same bytes always got "corrupted." I'm pretty sure its in the InputStreamReader() functionality where the conversion junk is happening. Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. I don't know if simply changing the cast is going to work. Since the conversion is happening upstream (pun intended), I don't think my cast is doing this. Also I think the compiler forced me to use the cast. I'm still playing around, and I'll report back once I nail it down. Thanks!! Keith From tjarvi at qbang.org Sat Mar 3 15:59:46 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 15:59:46 -0700 (MST) Subject: [Rxtx] Win64 rxtx Testers? Message-ID: I have compiled win64 binaries of rxtx. Are there any users interested in testing them? If so, I'll look into putting them on the web site. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Mar 3 15:35:06 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 14:35:06 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: Because of this and similar problems, JMRI does all it's serial IO using +only+ byte values. It's a but of a pain, as Java wants to go to char and int types a little too aggressively, but it does solve the "uncontrolled conversions" problems. Bob At 5:10 PM -0500 3/3/07, Keith wrote: >Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > >Bob -- I think you hit the nail on the head. > >I was just coming to the same realization here. I knew that something funny >was going on because the same bytes always got "corrupted." > >I'm pretty sure its in the InputStreamReader() functionality where the >conversion junk is happening. > >Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > >I don't know if simply changing the cast is going to work. Since the >conversion is happening upstream (pun intended), I don't think my cast is >doing this. Also I think the compiler forced me to use the cast. -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mark at mdsh.com Sun Mar 4 11:01:33 2007 From: mark at mdsh.com (Mark Himsley) Date: Sun, 04 Mar 2007 18:01:33 +0000 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: <5C01AC72C200388815C04982@bedroom.mdsh.local> On 03 March 2007 14:38 -0500 Keith wrote: > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT > consistent. Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? It looks like you need to use DataInputStream and DataOutputStream. -- Mark Himsley From tjarvi at qbang.org Sun Mar 4 11:35:08 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 11:35:08 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" > > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > > * Line #21 - Not sure if you need a (TM) mark for > the term "Sun" > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > OK. I'm going through this today. Some groups ask if rxtx could be under their license also. I think this is a good example of why I resist multiple licenses and focus on why the current license may not be usable by them. The RXTX project is a convergence of hobby and commercial interests. I happen to do both right now. The problem with licensing is we have to stay on top of them as they change. Clearly, adding more licenses will not make this easier. I'm acting as the hobby person today. RXTX always favors the hobby people. But as we move forward, I'm going to need to bring this to lawyers at work and explain to them what is going on. Others here may have to do this also. I don't anticipate problems or unexpected changes. The goal is a consistant, comprehendable and usable license as close to what we have now as possible. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 14:52:10 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 14:52:10 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (1/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: I'm breaking this into two parts. I expect the second part will need more attention. Comments first, then the changed material below. On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > Thanks > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. OK. RXTX for consitent use. java should not be capitalized because it does not only mean Sun [TM] Java [TM]. An example of this not meaning Java is when people use RXTX with GCJ. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". There are not any contributors that are in all of RXTX yet but I did update the comment to try to reflect the current situation without making it a nightmare to maintain. I looked to see how the Linux kernel does it as a reference point. > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" The URL can be problematic. I have done so below with a time reference. GNU does not provide version information in their URLS. I picture this being a problem when the version 3 comes out. > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > This will be corrected when the copy is updated to the version linked below. ---------------- begin proposed material involved -------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. ----------------- end proposed material involved -------------------- I'll be looking at the linking issue again next. That should be all that remains other than including the 2.1 version. Let me know if you have problems with anything here. I do not want to dilute the material I post next with these housekeeping tasks. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 16:08:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 16:08:36 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: For those that are wondering what is going on here, this next bit is the meat of the changes. We agreed a long time ago to put this disclaimer in. We did a so so job. It was in rxtx 2.0, not well written, ... So some groups using rxtx that would like to ship rxtx so users don't need to download, install, go to the mail-list to find why it failed, ... Then their legal teams tell them section 5 paragraph 2 is a show stopper. That was never the intent. Now going through what remains... > and might need a (TM) suffix to make Sun happy. Added disclaimer at the ended 'all trademarks belong...' > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. OK. As you can see I was trying to adjust GNU text there for the LGPL. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. used dynamically linked terminology. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". I tried to address this more upfront with an intent statement. Let me know if you have problems with it. I also tried to make it a little more clear what was derived from the GNU solution by moving the link location closer to GNU's suggestion. > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > Thats the intent. Here is the combined fixes. Note that only the material in /*-- --*/ is being touched. The new GPL license is there but unmodified. ------------------------ begin proposed new license ------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. | | An executable that contains no derivative of any portion of RXTX, but | is designed to work with RXTX by being dynamically linked with it, | is considered a "work that uses the Library" subject to the terms and | conditions of the GNU Lesser General Public License. | | The following has been added to the RXTX License to remove | any confusion about linking to RXTX. We want to allow in part what | section 5, paragraph 2 of the LGPL does not permit in the special | case of linking over a controlled interface. The intent is to add a | Java Specification Request or standards body defined interface in the | future as another exception but one is not currently available. | | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface | | As a special exception, the copyright holders of RXTX give you | permission to link RXTX with independent modules that communicate with | RXTX solely through the Sun Microsytems CommAPI interface version 2, | regardless of the license terms of these independent modules, and to copy | and distribute the resulting combined work under terms of your choice, | provided that every copy of the combined work is accompanied by a complete | copy of the source code of RXTX (the version of RXTX used to produce the | combined work), being distributed under the terms of the GNU Lesser General | Public License plus this exception. An independent module is a | module which is not derived from or based on RXTX. | | Note that people who make modified versions of RXTX are not obligated | to grant this special exception for their modified versions; it is | their choice whether to do so. The GNU Lesser General Public License | gives permission to release a modified version without this exception; this | exception also makes it possible to release a modified version which | carries forward this exception. | | You should have received a copy of the GNU Lesser General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA | All trademarks belong to their respective owners. --------------------------------------------------------------------------*/ The original GNU Lesser General Public License Follows. GNU LESSER GENERAL PUBLIC LICENSE Version 2.1, February 1999 Copyright (C) 1991, 1999 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. [This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence the version number 2.1.] Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This license, the Lesser General Public License, applies to some specially designated software packages--typically libraries--of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below. When we speak of free software, we are referring to freedom of use, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish); that you receive source code or can get it if you want it; that you can change the software and use pieces of it in new free programs; and that you are informed that you can do these things. To protect your rights, we need to make restrictions that forbid distributors to deny you these rights or to ask you to surrender these rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library or if you modify it. For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights. We protect your rights with a two-step method: (1) we copyright the library, and (2) we offer you this license, which gives you legal permission to copy, distribute and/or modify the library. To protect each distributor, we want to make it very clear that there is no warranty for the free library. Also, if the library is modified by someone else and passed on, the recipients should know that what they have is not the original version, so that the original author's reputation will not be affected by problems that might be introduced by others. Finally, software patents pose a constant threat to the existence of any free program. We wish to make sure that a company cannot effectively restrict the users of a free program by obtaining a restrictive license from a patent holder. Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license. Most GNU software, including some libraries, is covered by the ordinary GNU General Public License. This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs. When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library. We call this license the "Lesser" General Public License because it does Less to protect the user's freedom than the ordinary General Public License. It also provides other free software developers Less of an advantage over competing non-free programs. These disadvantages are the reason we use the ordinary General Public License for many libraries. However, the Lesser license provides advantages in certain special circumstances. For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License. In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software. For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU operating system, as well as its variant, the GNU/Linux operating system. Although the Lesser General Public License is Less protective of the users' freedom, it does ensure that the user of a program that is linked with the Library has the freedom and the wherewithal to run that program using a modified version of the Library. The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, whereas the latter must be combined with the library in order to run. GNU LESSER GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License Agreement applies to any software library or other program which contains a notice placed by the copyright holder or other authorized party saying it may be distributed under the terms of this Lesser General Public License (also called "this License"). Each licensee is addressed as "you". A "library" means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables. The "Library", below, refers to any such software library or work which has been distributed under these terms. A "work based on the Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term "modification".) "Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library. Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does. 1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) The modified work must itself be a software library. b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change. c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License. d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful. (For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library. In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. 4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange. If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code. 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables. When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law. If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.) Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself. 6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications. You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things: a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.) b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. c) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution. d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place. e) Verify that the user has already received a copy of these materials or that you have already sent this user a copy. For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute. 7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things: a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above. b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work. 8. You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 9. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Library (or any work based on the Library), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Library or works based on it. 10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties with this License. 11. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply, and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 12. If the distribution and/or use of the Library is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Library under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 13. The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation. 14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Libraries If you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the ordinary General Public License). To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Also add information on how to contact you by electronic and paper mail. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the library, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the library `Frob' (a library for tweaking knobs) written by James Random Hacker. , 1 April 1990 Ty Coon, President of Vice That's all there is to it! ------------------------ end of proposed license ------------------ -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sun Mar 4 16:26:04 2007 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 04 Mar 2007 17:26:04 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <45EB558C.3010609@cox.net> Bob Jacobsen wrote: > Because of this and similar problems, JMRI does all it's serial IO > using +only+ byte values. It's a but of a pain, as Java wants to go > to char and int types a little too aggressively, but it does solve > the "uncontrolled conversions" problems. Anytime that you are reading bytes of data that is not printable, unicode text, in Java, you really need to stay away from the Readers. Use input stream only, or you will see unicode valued byte groups converted to unicode "char" values. Gregg Wonderly From joachim at buechse.de Mon Mar 5 04:23:48 2007 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 5 Mar 2007 12:23:48 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> The behaviour is exactly what you asked for in you code. is = new BufferedReader(new InputStreamReader(port.getInputStream())); Readers return Text (ie unicode chars) not bytes. You instantiate the InputStreamReader without saying which charset you want, which means "platform default". As this is on Windows, it will convert Windows characters to equivalent unicode characters. If you want to read bytes, read bytes not Text. Reading bytes is done with InputStream and BufferedInputStream. BTW: The InputStream and Reader methods that read arrays are not guarenteed to fill up the array. You always have to check what you really got, and advance your index accordingly. A typical "read up to 32k" method looks like this: InputStream is= ... // -- determine the max buffer size int len= is.available(); if (len == 0) { len= 32 * 1024; } // -- read all available data byte[] buffer= new byte[len]; int pos= 0; int read; do { read= is.read(buffer, pos, buffer.length - pos); pos= pos + read; } while (read != -1 && pos < buffer.length); Best regards, Joachim --- Joachim B?chse Phone: +41 44 500 2604 Buechse Consulting Hadlaubsteig 2 CH-8006 Z?rich On 03.03.2007, at 23:10, Keith wrote: > Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > > Bob -- I think you hit the nail on the head. > > I was just coming to the same realization here. I knew that > something funny > was going on because the same bytes always got "corrupted." > > I'm pretty sure its in the InputStreamReader() functionality where the > conversion junk is happening. > > Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > > I don't know if simply changing the cast is going to work. Since the > conversion is happening upstream (pun intended), I don't think my > cast is > doing this. Also I think the compiler forced me to use the cast. > > I'm still playing around, and I'll report back once I nail it down. > > Thanks!! > > Keith > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Mon Mar 5 07:25:46 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 05 Mar 2007 08:25:46 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> Message-ID: <45EC286A.8060608@cox.net> Joachim Buechse wrote: > BTW: The InputStream and Reader methods that read arrays are not > guarenteed to fill up the array. You always have to check what you > really got, and advance your index accordingly. A typical "read up to > 32k" method looks like this: > > InputStream is= ... > // -- determine the max buffer size > int len= is.available(); > if (len == 0) { > len= 32 * 1024; > } > // -- read all available data > byte[] buffer= new byte[len]; > int pos= 0; > int read; > do { > read= is.read(buffer, pos, buffer.length - pos); > pos= pos + read; > } while (read != -1 && pos < buffer.length); > My preferred structure is. byte arr[ len ]; int cnt; int off = 0; while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { off += cnt; } This keeps you from adding -1 to pos when the read returns -1. It also skips out when the read is 0 bytes which, is not a described EOF in InputStream java docs, but is a condition I want to be aware of. Gregg Wonderly From joachim at buechse.de Tue Mar 6 02:52:58 2007 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 6 Mar 2007 10:52:58 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <45EC286A.8060608@cox.net> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: The code I copied was from a file resource reader, it shouldn't really be applied to networking/external IO code. Mea culpa. However aborting when you get 0 from read is not always what you want either (you kind of indicated that already). Some unix java implementations will return 0 if the kernel read was aborted with EINTER, which is rarely the point where you want to abort your read - at least not without further checks. A "complete" solution always depends on the events you need to handle and the time the total read could take in reality. In some cases it's worth checking Thread.isInterrupted() in the loop, some code re-loops on 0 but only a limited number of times, some check a total timeout limit, etc... Best regards, Joachim On 05.03.2007, at 15:25, Gregg Wonderly wrote: > My preferred structure is. > > byte arr[ len ]; > int cnt; > int off = 0; > while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { > off += cnt; > } > > This keeps you from adding -1 to pos when the read returns -1. It > also skips > out when the read is 0 bytes which, is not a described EOF in > InputStream java > docs, but is a condition I want to be aware of. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Mar 6 14:47:44 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 Mar 2007 14:47:44 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: Just FYI, rxtx will usually not break out on EINTER. The code in the native library usually does something close to this: do { read(...) } while ( !done && errno==EINTR ); Obviously there is a little more involved but it will retry on EINTER if not done. On Tue, 6 Mar 2007, Joachim Buechse wrote: > The code I copied was from a file resource reader, it shouldn't > really be applied to networking/external IO code. Mea culpa. > > However aborting when you get 0 from read is not always what you want > either (you kind of indicated that already). Some unix java > implementations will return 0 if the kernel read was aborted with > EINTER, which is rarely the point where you want to abort your read - > at least not without further checks. A "complete" solution always > depends on the events you need to handle and the time the total read > could take in reality. In some cases it's worth checking > Thread.isInterrupted() in the loop, some code re-loops on 0 but only > a limited number of times, some check a total timeout limit, etc... > > Best regards, > Joachim > > On 05.03.2007, at 15:25, Gregg Wonderly wrote: >> My preferred structure is. >> >> byte arr[ len ]; >> int cnt; >> int off = 0; >> while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { >> off += cnt; >> } >> >> This keeps you from adding -1 to pos when the read returns -1. It >> also skips >> out when the read is 0 bytes which, is not a described EOF in >> InputStream java >> docs, but is a condition I want to be aware of. >> >> Gregg Wonderly >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 gjhanna at gmail.com Thu Mar 8 13:42:52 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Fri, 9 Mar 2007 09:42:52 +1300 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? Message-ID: I've just struck an issue using rxtx in a multi-threaded environment: If I have 3 threads trying to open *the same* comm-port I get a deadlock in CommPortIdentifier.open If I have just 2, it works fine - I get a PortInUseException which is nice and I can handle it. The 3 thread->deadlock thing is causing me issues. (Sample code below). This is from the java thread-dump Found one Java-level deadlock: ============================= "Thread-2": waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object ), which is held by "Thread-1" "Thread-1": waiting to lock monitor 0x0003e9cc (object 0x2450e108, a gnu.io.CommPortIdentifier), which is held by "Thread-2" Java stack information for the threads listed above: =================================================== "Thread-2": at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:329) - waiting to lock <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) "Thread-1": at java.lang.Object.wait(Native Method) - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) - locked <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) (Apart from this, rxtx is working fantastically for us). I'm thinking I'll have to implement some sort of locking mechanism that *doesn't* use java synchronization to prevent this situation. (Which doesn't sound like a good idea to me). Any ideas? Thanks, Greg Hanna ============= RXTXLockTest.java ======================================== import gnu.io.CommPort; import gnu.io.CommPortIdentifier; /** * @author Greg Hanna * Minimal code to create a deadlock with rxtx in multithreaded open */ public class RXTXLockTest { public static void main(String[] args) { try { CommPortIdentifier cpiCom1 = CommPortIdentifier.getPortIdentifier ("COM14"); OpenThread t1 = new OpenThread (" one ", cpiCom1); OpenThread t2 = new OpenThread (" two ", cpiCom1); OpenThread t3 = new OpenThread (" 003 ", cpiCom1); t1.start(); t2.start(); t3.start(); // comment this out and it runs with (expected) PortInUseException } catch (Exception e) { e.printStackTrace(); } } } class OpenThread extends Thread { String name; CommPortIdentifier cpi; CommPort cp; public OpenThread (String name, CommPortIdentifier cpi) { this.name = name; this.cpi = cpi; System.out.println (System.currentTimeMillis() + name + " thread created"); } public void run () { try { System.out.println (System.currentTimeMillis() + name + " opening"); cp = cpi.open(name, 2000); System.out.println (System.currentTimeMillis() + name + " opened - sleeping"); sleep (2000); // do the serial comms with the device. System.out.println (System.currentTimeMillis() + name + " slept - closing"); cp.close(); System.out.println (System.currentTimeMillis() + name + " closed - exiting"); } catch (Exception e) { System.out.println ("Error in thread: " + name ); e.printStackTrace(); } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070308/d9a163c5/attachment-0003.html From eu259473 at tele2.it Fri Mar 9 02:46:20 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 09 Mar 2007 10:46:20 +0100 Subject: [Rxtx] rxtx: tru64 unix make fails Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070309/3b654523/attachment-0003.html From lyon at docjava.com Fri Mar 9 03:58:32 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 Mar 2007 05:58:32 -0500 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi All, The deadlock issue is one that I have been thinking about for some time now. It seems to me that we need a resource manager that enables assignment to a known process. The one thing that seems important about serial ports is that two applications should not use the same serial port at the same time. When this happens, it throws an exception. OK. The exception is a response to a lock condition that arises from an unavailable resource. An abstract implementation (not born of native methods) might assign a serial port to an application, until the application releases it (or is forced to release it by some kill mechanism). Some resources (like a registry) can be reused. But others, like the serial port, cannot. In the case of the serial port, we would like, I think, to have the flyweight design pattern without sharing and with object assignment tracking. A means of breaking deadlock (like a leasing mechanism) seems very useful, to me. My guess is that we can serialize the state of the Parametric Singleton Pattern (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) into the Preferences of the System. Preferences.systemRoot() might help with that. When a resource is checked out, the lease time and owner are listed. A thread that does this can be killed, but applications outside of Java are problematic. There is a compelling problem here. It is not just serial ports. Sound cards, cameras, microphones, files, tape drives, etc. All are consumed resources that are assigned to an application (or user) and deprive other applications, or users, from use. What, if anything, should we do? At present we throw PortInUseExceptions. Is that it? Can we do better? OK, the port is in use. Now what? Do I have to be root to go remove lock files and kill applications? Is there a better way? Thanks! - Doug >I've just struck an issue using rxtx in a multi-threaded environment: > >If I have 3 threads trying to open *the same* >comm-port I get a deadlock in >CommPortIdentifier.open >If I have just 2, it works fine - I get a >PortInUseException which is nice and I can >handle it. > >The 3 thread->deadlock thing is causing me issues. >(Sample code below). > >This is from the java thread-dump > >Found one Java-level deadlock: >============================= >"Thread-2": > waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), > which is held by "Thread-1" >"Thread-1": > waiting to lock monitor 0x0003e9cc (object >0x2450e108, a gnu.io.CommPortIdentifier ), > which is held by "Thread-2" > >Java stack information for the threads listed above: >=================================================== >"Thread-2": > at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) > - waiting to lock <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) >"Thread-1": > at java.lang.Object.wait(Native Method) > - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) > - locked <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) > > >(Apart from this, rxtx is working fantastically for us). > >I'm thinking I'll have to implement some sort of >locking mechanism that *doesn't* use java >synchronization to prevent this situation. >(Which doesn't sound like a good idea to me). > >Any ideas? > >Thanks, > >Greg Hanna > >============= RXTXLockTest.java ======================================== > >import gnu.io.CommPort; >import gnu.io.CommPortIdentifier; > >/** > * @author Greg Hanna > * Minimal code to create a deadlock with rxtx in multithreaded open > */ >public class RXTXLockTest { > ? > ?public static void main(String[] args) { > ?try { > ?CommPortIdentifier cpiCom1 = >CommPortIdentifier.getPortIdentifier ("COM14"); > ?OpenThread t1 = new OpenThread (" one ", cpiCom1); > ?OpenThread t2 = new OpenThread (" two ", cpiCom1); > ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); > ?t1.start(); > ?t2.start(); > ?t3.start(); // comment this out >and it runs with (expected) PortInUseException > ?} catch (Exception e) { > ?e.printStackTrace(); > ?} > ?} >} > >class OpenThread extends Thread { > ?String name; > ?CommPortIdentifier cpi; > ?CommPort cp; > ?public OpenThread (String name, CommPortIdentifier cpi) { > ? this.name = name; > ?this.cpi = cpi; > ?System.out.println >(System.currentTimeMillis() + name + " thread >created"); > ?} > ?public void run () { > ?try { > ?System.out.println >(System.currentTimeMillis() + name + " opening"); > ?cp = cpi.open(name, 2000); > ?System.out.println >(System.currentTimeMillis() + name + " opened - >sleeping"); > ?sleep (2000); // do the serial comms with the device. > ?System.out.println >(System.currentTimeMillis() + name + " slept - >closing"); > ?cp.close(); > ?System.out.println >(System.currentTimeMillis() + name + " closed - >exiting"); > ?} catch (Exception e) { > System.out.println ("Error in thread: " + name ); > ?e.printStackTrace(); > ?} > ?} >} > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Mar 9 06:37:45 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 Mar 2007 06:37:45 -0700 (MST) Subject: [Rxtx] rxtx: tru64 unix make fails In-Reply-To: References: Message-ID: On Fri, 9 Mar 2007, "Giuseppe Marchese" wrote: > Sorry for delay. > ? > This is log for ./configure and make > error. > ? > thanks for attention > ? > Make: '%.java,$(TOP)/$(CLASSDEST)/%.class,$(wildcard $(SPATH)/*.java)': extra chars.? > Stop. > Hi Giuseppe You need to use GNU make with the Makefile. I suspect the tru64 make is not happy with those rules. > configure: exit 0 Looks like configure is fairly happy. From tjarvi at qbang.org Sat Mar 10 07:43:51 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 07:43:51 -0700 (MST) Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi Doug I have very little time to look into this further but what we could do is open up an rxtx 3 devel branch in which a proof of concept could be worked on. It could be the proof of concept for a JSR others including Sun could look at/work on or parts of it could be recycled in a JSR. I'm working very hard on rxtx right now but it does not show. I'm looking at win64, mac intel/ppc, usb bluetooth and usb serial dongles. Some are going to be more tested than others but they are all on the plate. I'll be pushing all the fixes upstream when they are done. So I'm very busy in 2.1 but we could open a new branch. On Fri, 9 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > The deadlock issue is one that I have been thinking about > for some time now. > It seems to me that we need a resource manager that enables assignment > to a known process. > > The one thing that seems important about serial > ports is that two applications should not use the > same serial port at the same time. When this > happens, it throws an exception. > OK. > > The exception is a response to a lock condition that > arises from an unavailable resource. > > An abstract implementation (not born of native methods) might > assign a serial port to an application, until the > application releases it (or is forced to release > it by some kill mechanism). > > Some resources (like a registry) can be reused. > But others, like the serial port, > cannot. > > In the case of the serial port, we would like, I think, to > have the flyweight design pattern > without sharing and with object assignment tracking. > A means of breaking deadlock (like a leasing > mechanism) seems very useful, to me. > > My guess is that we can serialize the state of the Parametric Singleton Pattern > (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) > into the Preferences of the System. Preferences.systemRoot() might help > with that. When a resource is checked out, the lease time and owner are > listed. A thread that does this can be killed, but applications outside of Java > are problematic. > > There is a compelling problem here. It is not just serial ports. > Sound cards, cameras, microphones, files, tape drives, etc. All are consumed > resources that are assigned to an application (or > user) and deprive other applications, > or users, from use. > > What, if anything, should we do? At present we throw PortInUseExceptions. > Is that it? > Can we do better? > OK, the port is in use. Now what? > Do I have to be root to go remove lock files and kill applications? > Is there a better way? > > Thanks! > - Doug > >> I've just struck an issue using rxtx in a multi-threaded environment: >> >> If I have 3 threads trying to open *the same* >> comm-port I get a deadlock in >> CommPortIdentifier.open >> If I have just 2, it works fine - I get a >> PortInUseException which is nice and I can >> handle it. >> >> The 3 thread->deadlock thing is causing me issues. >> (Sample code below). >> >> This is from the java thread-dump >> >> Found one Java-level deadlock: >> ============================= >> "Thread-2": >> waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), >> which is held by "Thread-1" >> "Thread-1": >> waiting to lock monitor 0x0003e9cc (object >> 0x2450e108, a gnu.io.CommPortIdentifier ), >> which is held by "Thread-2" >> >> Java stack information for the threads listed above: >> =================================================== >> "Thread-2": >> at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) >> - waiting to lock <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> "Thread-1": >> at java.lang.Object.wait(Native Method) >> - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) >> - locked <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> >> >> (Apart from this, rxtx is working fantastically for us). >> >> I'm thinking I'll have to implement some sort of >> locking mechanism that *doesn't* use java >> synchronization to prevent this situation. >> (Which doesn't sound like a good idea to me). >> >> Any ideas? >> >> Thanks, >> >> Greg Hanna >> >> ============= RXTXLockTest.java ======================================== >> >> import gnu.io.CommPort; >> import gnu.io.CommPortIdentifier; >> >> /** >> * @author Greg Hanna >> * Minimal code to create a deadlock with rxtx in multithreaded open >> */ >> public class RXTXLockTest { >> ? >> ?public static void main(String[] args) { >> ?try { >> ?CommPortIdentifier cpiCom1 = >> CommPortIdentifier.getPortIdentifier ("COM14"); >> ?OpenThread t1 = new OpenThread (" one ", cpiCom1); >> ?OpenThread t2 = new OpenThread (" two ", cpiCom1); >> ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); >> ?t1.start(); >> ?t2.start(); >> ?t3.start(); // comment this out >> and it runs with (expected) PortInUseException >> ?} catch (Exception e) { >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> class OpenThread extends Thread { >> ?String name; >> ?CommPortIdentifier cpi; >> ?CommPort cp; >> ?public OpenThread (String name, CommPortIdentifier cpi) { >> ? this.name = name; >> ?this.cpi = cpi; >> ?System.out.println >> (System.currentTimeMillis() + name + " thread >> created"); >> ?} >> ?public void run () { >> ?try { >> ?System.out.println >> (System.currentTimeMillis() + name + " opening"); >> ?cp = cpi.open(name, 2000); >> ?System.out.println >> (System.currentTimeMillis() + name + " opened - >> sleeping"); >> ?sleep (2000); // do the serial comms with the device. >> ?System.out.println >> (System.currentTimeMillis() + name + " slept - >> closing"); >> ?cp.close(); >> ?System.out.println >> (System.currentTimeMillis() + name + " closed - >> exiting"); >> ?} catch (Exception e) { >> System.out.println ("Error in thread: " + name ); >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 mm at UDel.Edu Sat Mar 10 14:48:32 2007 From: mm at UDel.Edu (Mike Markowski) Date: Sat, 10 Mar 2007 16:48:32 -0500 Subject: [Rxtx] rxtx and Sun's comm api Message-ID: <45F327B0.2060004@udel.edu> Hi all, I joined the list a few days ago and apologize for what is likely a frequently asked question, though I haven't yet found it anywhere. I learned about rxtx.org through the readme on Sun's version 2 of their comms api. They give recommendations in that readme regarding how a better comms api should be written. Is this the aim of rxtx.org? I wrote an app on my linux box using the Sun comms api (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the fact that only linux and Solaris are supported. So I'm glad to find rxtx.org and am just reading up on how make the conversion so Windows users will be able to run the program as well. At the same time I'm just curious if rxtx.org and Sun are both heading in the same direction. Thanks for any background or historical info. Feel free to point me to any www pages if my googling has just completely missed the target! Thanks again, Mike From tjarvi at qbang.org Sat Mar 10 15:35:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 15:35:25 -0700 (MST) Subject: [Rxtx] rxtx and Sun's comm api In-Reply-To: <45F327B0.2060004@udel.edu> References: <45F327B0.2060004@udel.edu> Message-ID: On Sat, 10 Mar 2007, Mike Markowski wrote: > Hi all, > > I joined the list a few days ago and apologize for what is likely a > frequently asked question, though I haven't yet found it anywhere. I > learned about rxtx.org through the readme on Sun's version 2 of their > comms api. They give recommendations in that readme regarding how a > better comms api should be written. Is this the aim of rxtx.org? > > I wrote an app on my linux box using the Sun comms api > (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the > fact that only linux and Solaris are supported. So I'm glad to find > rxtx.org and am just reading up on how make the conversion so Windows > users will be able to run the program as well. At the same time I'm > just curious if rxtx.org and Sun are both heading in the same direction. > > Thanks for any background or historical info. Feel free to point me to > any www pages if my googling has just completely missed the target! > I do not have any news (good or bad) concerning RXTX and Sun working together but perhaps others here do. The main goal of RXTX is to expose POSIX termios interfaces to java users. The future support of javax.comm is questionable. We do not have resources for everything. gnu.io (RXTX 2.1) will be supported going forward and functions the same as CommAPI 2.0. If you have control of the source code you are working with, I would not advise using CommAPI 2.0 javax.comm. We do support CommAPI 2.0 javax.comm for older applications but I do not think that will last much longer for practical reasons. The download interest in CommAPI 2.0 javax.comm support is becomming negligible on this end. There has been discussion of a JSR effort but I do not know of any status change since it was mentioned. One problem with a JSR is that even a light weight process is going to be difficult for RXTX at this time. Maybe that will change in the future but then again it may not. For now, we are just going forward 'as is' in rxtx 2.1 with package gnu.io while trying as a secondary effort to backport the changes to rxtx 2.0 for javax.comm support for users that do not have a choice. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Mar 11 07:19:40 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 11 Mar 2007 08:19:40 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: Hi All, I have been a proponent of a JSR that makes use of RXTX. I have executed the proper agreements with Sun. At this point we are in the: Early Draft Review of Draft Specifications Stage. The best thing to do is to enter the quiet period and create a specification. The question of exactly how we, as a group, want to approach this problem, remains open. Typically, we should have both a specification and a reference implementation. Thus, it would be to our best advantage to have a nice, stable, cross platform RXTX distro that adheres to the groups specification. Now, from a specification standpoint, my personal view on the matter is that we create a series of interfaces, with nice documentation (or at least javadoc). Is this a good idea? Should we have a pure interface specification for the communication API? There are several issues, in my mind, which still weigh on us. Hot-pluggable dongles, long discovery process on pop-up ports, lack of uniformity on device names, lack of uniformity on locking, a precise understanding of how the SerialPortResourceManager works (or even if we should have one). The more questions we answer in our reference implementation, the better our specification will get. RXTX is a good working prototype, but, I don't know if that is what we want to use for a specification. Here is what I have for a CommPortInterface: */ public interface CommPortInterface { /** * @return a string representation of this port. */ String toString(); /** * Gets the name of the communications port. This name should correspond to * something the user can identify, like the label on the hardware. * @return name of the port */ String getName(); /** * @return an input stream that can be used to read data from the * communications port. If the port doesn't support reading data, this * method returns null. *

* The blocking behaviour of this input stream depends on the threshold * and timeout values, as shown below for a read buffer size of n * bytes: * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ThresholdTimeoutBlocking behaviour
StateValueStateValue
disableddisabledblock until data is available
enabledm bytesdisabledblock until min(m, n) bytes are available
disabledenabledt msblock for t ms or until data is available
enabledm bytesenabledt msblock for t ms or until min(m, n) bytes are * available
* @throws java.io.IOException */ InputStream getInputStream() throws IOException; /** * @return an output stream that can be used to send data to the * communications port. If the port doesn't support sending data, this * method returns null. * @throws java.io.IOException */ OutputStream getOutputStream() throws IOException; /** * Closes this communications port. * All PortOwnershipListeners will be? * notified of this change of ownership. Further method calls on this? * object will throw IllegalStateException. Further calls on the? * associated InputStream or OutputStream will throw IOException. *

* Close does not block. Undelivered data is discarded. Blocked read and? * write operations are aborted if the underlying operating systems? * supports an IO abort mechanism. To await the delivery of undelivered? * data call OutputStream.flush() or OutputStream.close() before calling? * Port.close(). */ void close(); /** * Enables receive threshold. * When the specified threshold number of bytes are retrieved, read will * return immediately. * * @param thresh the number of bytes in the input buffer * @throws gnu.io.UnsupportedCommOperationException * if receive threshold is * not supported by the driver * @see #disableReceiveThreshold */ void enableReceiveThreshold(int thresh) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive threshold. * * @see #enableReceiveThreshold */ void disableReceiveThreshold(); /** * @return true if receive threshold is enabled. * * @see #enableReceiveThreshold */ boolean isReceiveThresholdEnabled(); /** * @return the receive threshold value. If receive threshold is diabled * or not supported, this value is meaningless. * * @see #enableReceiveThreshold */ int getReceiveThreshold(); /** * Enables receive timeout. * When the specified number of milliseconds have elapsed, read will * return immediately. * * @param rcvTimeout the number of milliseconds to block for * @throws gnu.io.UnsupportedCommOperationException * if receive timeout is * not supported by the driver * @see #disableReceiveTimeout */ void enableReceiveTimeout(int rcvTimeout) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive timeout. * * @see #enableReceiveTimeout */ void disableReceiveTimeout(); /** * @return true if receive timeout is enabled. * * @see #enableReceiveTimeout */ boolean isReceiveTimeoutEnabled(); /** * @return the receive timeout value. If receive timeout is diabled * or not supported, this value is meaningless. * * @see #enableReceiveTimeout */ int getReceiveTimeout(); /** * Enables receive framing. * The supplied byte value in the input suggests the end of the received * frame, and read returns immediately. Only the low 8 bits of the * supplied value are significant. * * @param framingByte the frame delimiter * @throws gnu.io.UnsupportedCommOperationException * if receive framing is * not supported by the driver * @see #disableReceiveFraming */ void enableReceiveFraming(int framingByte) throws UnsupportedCommOperationException; /** * Disables receive framing. * * @see #enableReceiveFraming */ void disableReceiveFraming(); /** * @return true if receive framing is enabled. * * @see #enableReceiveFraming */ boolean isReceiveFramingEnabled(); /** * @return true if receive framing byte. If receive framing is diabled * or not supported, this value is meaningless. * * @see #enableReceiveFraming */ int getReceiveFramingByte(); /** * Sets the input buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setInputBufferSize(int size); /** * @return the input buffer size. * The driver may choose not to report correct values. */ int getInputBufferSize(); /** * Sets the output buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setOutputBufferSize(int size); /** * @return the output buffer size. * The driver may choose not to report correct values. */ int getOutputBufferSize(); } What do you think of that? Note the wishy washy nature of the spec: The driver may choose to ignore this method. Is that good enough for us? Thanks! - Doug From ra85551 at gmail.com Sun Mar 11 08:44:45 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Sun, 11 Mar 2007 17:44:45 +0300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hello, world! I am writing application that communicates with modem via AT commands. My OS is Linux Kubuntu Feisty Herd, to ensure that my application will run properly under Windows XP I installed VMWare server. When I tried to send AT command and evaluate modem answer under WinXP @ VMWare server, I actually didn't receive anything. I think that VM settings are right, because I do can communicate with modem by using standard HyperTerminall as well as I can do on native Windows. So, why RXTX doesn't work under VM, but works under Linux and pure Windows XP (i tested it there) well? The send/receive method code follows. private String sendATCommand(String command, final String waitFor, final boolean isRegex, boolean isAddCRLF, long timeout) throws BeaconConnectException { final long POLL_PERIOD = 100; final int BUFFER_SIZE = 512; final byte[] buffer = new byte[BUFFER_SIZE]; final InputStream serialInput; final OutputStream serialOutput; try { serialInput = serialPort.getInputStream(); if (command != null) { serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } } catch (IOException e) { throw new MyException("serial I/O error"); } TimerTask task = new TimerTask() { int offset = 0; int bytesRead; public synchronized void run() { try { if (serialInput.available() > 0) { bytesRead = serialInput.read(buffer, offset, BUFFER_SIZE - offset); } else { return; } } catch (IOException e) { // do nothing - maybe next time we'll read something } offset += bytesRead; if (waitFor != null) { String temporary = new String(buffer, 0, offset).trim(); if (isRegex && temporary.matches(waitFor) || temporary.contains(waitFor)) { cancel(); notify(); } } } }; Timer timer = new Timer(); timer.schedule(task, POLL_PERIOD, POLL_PERIOD); synchronized (task) { try { task.wait(timeout); task.cancel(); } catch (InterruptedException e) { } } //Cut off leading and trailing CRs, LFs and zeroes String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); System.out.println(response); return response; } -- Pavel Parkhomenko From tjarvi at qbang.org Sun Mar 11 11:48:22 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:48:22 -0600 (MDT) Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: On Sun, 11 Mar 2007, Pavel Parkhomenko wrote: > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. > > private String sendATCommand(String command, final String waitFor, > final boolean isRegex, boolean isAddCRLF, long timeout) > throws BeaconConnectException > { > final long POLL_PERIOD = 100; > final int BUFFER_SIZE = 512; > final byte[] buffer = new byte[BUFFER_SIZE]; > final InputStream serialInput; > final OutputStream serialOutput; > try > { > serialInput = serialPort.getInputStream(); > if (command != null) > { > serialOutput = serialPort.getOutputStream(); > if (isAddCRLF) > { > command += "\r\n"; > } > System.out.println(command); > serialOutput.write(command.getBytes()); > } > } > catch (IOException e) > { > throw new MyException("serial I/O error"); > } > > TimerTask task = new TimerTask() > { > int offset = 0; > int bytesRead; > public synchronized void run() > { > try > { > if (serialInput.available() > 0) > { > bytesRead = serialInput.read(buffer, offset, > BUFFER_SIZE - offset); > } > else > { > return; > } > } > catch (IOException e) > { > // do nothing - maybe next time we'll read something > } > offset += bytesRead; > if (waitFor != null) > { > String temporary = new String(buffer, 0, offset).trim(); > if (isRegex && temporary.matches(waitFor) || > temporary.contains(waitFor)) > { > cancel(); > notify(); > } > } > } > }; > > Timer timer = new Timer(); > timer.schedule(task, POLL_PERIOD, POLL_PERIOD); > synchronized (task) { > try > { > task.wait(timeout); > task.cancel(); > } > catch (InterruptedException e) > { > } > } > //Cut off leading and trailing CRs, LFs and zeroes > String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); > System.out.println(response); > return response; > } > > > Hi Pavel VMWare should not be a problem. I've used it in the past - though not with a modem. Make sure nothing else is using the modem. Then look in the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an example that should work. Note that modems could care less what OS is on top. If you are trying to match new lines to the OS and sending it to the mode for AT commands, thats probably a mistake. Also it would not hurt to print out the individual bytes that you are sending to make sure they did not get mangled along the path. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 11:55:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:55:48 -0600 (MDT) Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: On Sun, 11 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > I have been a proponent of a JSR that makes > use of RXTX. I have executed the proper agreements with Sun. > > At this point we are in the: > Early Draft Review of Draft Specifications Stage. > > The best thing to do is to enter the quiet period and create > a specification. The question of exactly how we, as a group, > want to approach this problem, remains open. > > Typically, we should have both a specification and a reference > implementation. Thus, it would be to our best advantage to have > a nice, stable, cross platform RXTX distro that adheres to the > groups specification. > > Now, from a specification standpoint, my personal view on the matter is > that we create a series of interfaces, with nice documentation (or at least > javadoc). > > Is this a good idea? Should we have a pure interface specification for > the communication API? > > There are several issues, in my mind, which still weigh on us. > Hot-pluggable dongles, long discovery process on pop-up ports, > lack of uniformity on device names, lack of uniformity on locking, > a precise understanding of how the SerialPortResourceManager > works (or even if we should have one). > > The more questions we answer in our reference implementation, the > better our specification will get. RXTX is a good working prototype, > but, I don't know if that is what we want to use for a specification. > > Here is what I have for a CommPortInterface: > */ > public interface CommPortInterface { Hi Doug, I can start going through the method interfaces later this week and giving feedback. I would suggest that the JSR should not be too generic in nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel drivers that intend to look like EIA232 ports at the kernel driver level. some ideas: EIA232PortInterface TermiosInterface SerialPortInterface Something that differentiates this from thing like USB, I2C, ... which should not have to deal with legacy serial claiming to be the comm api. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 12:52:19 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 12:52:19 -0600 (MDT) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: No news is good news with these posts. I'll start the process of pinging legal a week from Monday on my end if nobody has objections to the proposal. I just want to make sure everyone has time to raise objections. Obviously, anyone can fork from a previous version if they don't like the new license. I suspect we can avoid that though. On Sun, 4 Mar 2007, Trent Jarvi wrote: > > For those that are wondering what is going on here, this > next bit is the meat of the changes. We agreed a long time > ago to put this disclaimer in. We did a so so job. It was > in rxtx 2.0, not well written, ... So some groups using > rxtx that would like to ship rxtx so users don't need to > download, install, go to the mail-list to find why it failed, > ... Then their legal teams tell them section 5 paragraph 2 > is a show stopper. > > That was never the intent. > > > Now going through what remains... > >> and might need a (TM) suffix to make Sun happy. > > Added disclaimer at the ended 'all trademarks belong...' > >> * Line #15ff - static vs. dynamic linking - you did >> not transcribe the text from the "controlled >> interface exception" when writing this text - and >> this was good so, because these terms originally >> refer to the GPL rather than the LGPL. I think though, >> that these 4 lines are the most important ones and >> should thus be really really clear. I hope that I >> meet your original intent with the following >> suggestions: >> 1.) Instead of "A program.." it would be better to >> say "An exectuable.." in order to be closer to >> the LGPL text. > > OK. As you can see I was trying to adjust GNU text there > for the LGPL. > >> 2.) It would be better to say .. "by being dynamically >> linked with it" to clearly indicate that dynamic >> linking is meant. The matter of compilation is >> already covered by the LGPL so mentioning it again >> just leads to confusion. > > used dynamically linked terminology. > >> 3.) It would be better to say .. "is considered a >> work that uses the library in contrast to section >> 5 of the LGPL, so the terms of the LGPL do not >> apply to the resulting executable". > > I tried to address this more upfront with an intent statement. > Let me know if you have problems with it. I also tried to > make it a little more clear what was derived from the GNU > solution by moving the link location closer to GNU's suggestion. > >> >> Note that LGPL section 5 says: ..."is called a >> "work that uses the Library". Such a work, in isolation, >> is not a derivative work of the Library, and therefore >> falls outside the scope of this License." >> The next paragraph of the LGPL is exactly the problematic >> one that I hope is clarified by the exception terms you >> give. >> > > Thats the intent. Here is the combined fixes. Note that only the > material in /*-- --*/ is being touched. The new GPL license is > there but unmodified. > > > ------------------------ begin proposed new license ------------------- > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Lesser General Public > | License as published by the Free Software Foundation; either > | version 2.1 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Lesser General Public License for more details. > | > | An executable that contains no derivative of any portion of RXTX, but > | is designed to work with RXTX by being dynamically linked with it, > | is considered a "work that uses the Library" subject to the terms and > | conditions of the GNU Lesser General Public License. > | > | The following has been added to the RXTX License to remove > | any confusion about linking to RXTX. We want to allow in part what > | section 5, paragraph 2 of the LGPL does not permit in the special > | case of linking over a controlled interface. The intent is to add a > | Java Specification Request or standards body defined interface in the > | future as another exception but one is not currently available. > | > | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface > | > | As a special exception, the copyright holders of RXTX give you > | permission to link RXTX with independent modules that communicate with > | RXTX solely through the Sun Microsytems CommAPI interface version 2, > | regardless of the license terms of these independent modules, and to copy > | and distribute the resulting combined work under terms of your choice, > | provided that every copy of the combined work is accompanied by a complete > | copy of the source code of RXTX (the version of RXTX used to produce the > | combined work), being distributed under the terms of the GNU Lesser General > | Public License plus this exception. An independent module is a > | module which is not derived from or based on RXTX. > | > | Note that people who make modified versions of RXTX are not obligated > | to grant this special exception for their modified versions; it is > | their choice whether to do so. The GNU Lesser General Public License > | gives permission to release a modified version without this exception; this > | exception also makes it possible to release a modified version which > | carries forward this exception. > | > | You should have received a copy of the GNU Lesser General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > | All trademarks belong to their respective owners. > --------------------------------------------------------------------------*/ > > The original GNU Lesser General Public License Follows. > > > GNU LESSER GENERAL PUBLIC LICENSE > Version 2.1, February 1999 > > Copyright (C) 1991, 1999 Free Software Foundation, Inc. > 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > Everyone is permitted to copy and distribute verbatim copies > of this license document, but changing it is not allowed. > > [This is the first released version of the Lesser GPL. It also counts > as the successor of the GNU Library Public License, version 2, hence > the version number 2.1.] > > Preamble > > The licenses for most software are designed to take away your > freedom to share and change it. By contrast, the GNU General Public > Licenses are intended to guarantee your freedom to share and change > free software--to make sure the software is free for all its users. > > This license, the Lesser General Public License, applies to some > specially designated software packages--typically libraries--of the > Free Software Foundation and other authors who decide to use it. You > can use it too, but we suggest you first think carefully about whether > this license or the ordinary General Public License is the better > strategy to use in any particular case, based on the explanations below. > > When we speak of free software, we are referring to freedom of use, > not price. Our General Public Licenses are designed to make sure that > you have the freedom to distribute copies of free software (and charge > for this service if you wish); that you receive source code or can get > it if you want it; that you can change the software and use pieces of > it in new free programs; and that you are informed that you can do > these things. > > To protect your rights, we need to make restrictions that forbid > distributors to deny you these rights or to ask you to surrender these > rights. These restrictions translate to certain responsibilities for > you if you distribute copies of the library or if you modify it. > > For example, if you distribute copies of the library, whether gratis > or for a fee, you must give the recipients all the rights that we gave > you. You must make sure that they, too, receive or can get the source > code. If you link other code with the library, you must provide > complete object files to the recipients, so that they can relink them > with the library after making changes to the library and recompiling > it. And you must show them these terms so they know their rights. > > We protect your rights with a two-step method: (1) we copyright the > library, and (2) we offer you this license, which gives you legal > permission to copy, distribute and/or modify the library. > > To protect each distributor, we want to make it very clear that > there is no warranty for the free library. Also, if the library is > modified by someone else and passed on, the recipients should know > that what they have is not the original version, so that the original > author's reputation will not be affected by problems that might be > introduced by others. > > Finally, software patents pose a constant threat to the existence of > any free program. We wish to make sure that a company cannot > effectively restrict the users of a free program by obtaining a > restrictive license from a patent holder. Therefore, we insist that > any patent license obtained for a version of the library must be > consistent with the full freedom of use specified in this license. > > Most GNU software, including some libraries, is covered by the > ordinary GNU General Public License. This license, the GNU Lesser > General Public License, applies to certain designated libraries, and > is quite different from the ordinary General Public License. We use > this license for certain libraries in order to permit linking those > libraries into non-free programs. > > When a program is linked with a library, whether statically or using > a shared library, the combination of the two is legally speaking a > combined work, a derivative of the original library. The ordinary > General Public License therefore permits such linking only if the > entire combination fits its criteria of freedom. The Lesser General > Public License permits more lax criteria for linking other code with > the library. > > We call this license the "Lesser" General Public License because it > does Less to protect the user's freedom than the ordinary General > Public License. It also provides other free software developers Less > of an advantage over competing non-free programs. These disadvantages > are the reason we use the ordinary General Public License for many > libraries. However, the Lesser license provides advantages in certain > special circumstances. > > For example, on rare occasions, there may be a special need to > encourage the widest possible use of a certain library, so that it becomes > a de-facto standard. To achieve this, non-free programs must be > allowed to use the library. A more frequent case is that a free > library does the same job as widely used non-free libraries. In this > case, there is little to gain by limiting the free library to free > software only, so we use the Lesser General Public License. > > In other cases, permission to use a particular library in non-free > programs enables a greater number of people to use a large body of > free software. For example, permission to use the GNU C Library in > non-free programs enables many more people to use the whole GNU > operating system, as well as its variant, the GNU/Linux operating > system. > > Although the Lesser General Public License is Less protective of the > users' freedom, it does ensure that the user of a program that is > linked with the Library has the freedom and the wherewithal to run > that program using a modified version of the Library. > > The precise terms and conditions for copying, distribution and > modification follow. Pay close attention to the difference between a > "work based on the library" and a "work that uses the library". The > former contains code derived from the library, whereas the latter must > be combined with the library in order to run. > > GNU LESSER GENERAL PUBLIC LICENSE > TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION > > 0. This License Agreement applies to any software library or other > program which contains a notice placed by the copyright holder or > other authorized party saying it may be distributed under the terms of > this Lesser General Public License (also called "this License"). > Each licensee is addressed as "you". > > A "library" means a collection of software functions and/or data > prepared so as to be conveniently linked with application programs > (which use some of those functions and data) to form executables. > > The "Library", below, refers to any such software library or work > which has been distributed under these terms. A "work based on the > Library" means either the Library or any derivative work under > copyright law: that is to say, a work containing the Library or a > portion of it, either verbatim or with modifications and/or translated > straightforwardly into another language. (Hereinafter, translation is > included without limitation in the term "modification".) > > "Source code" for a work means the preferred form of the work for > making modifications to it. For a library, complete source code means > all the source code for all modules it contains, plus any associated > interface definition files, plus the scripts used to control compilation > and installation of the library. > > Activities other than copying, distribution and modification are not > covered by this License; they are outside its scope. The act of > running a program using the Library is not restricted, and output from > such a program is covered only if its contents constitute a work based > on the Library (independent of the use of the Library in a tool for > writing it). Whether that is true depends on what the Library does > and what the program that uses the Library does. > > 1. You may copy and distribute verbatim copies of the Library's > complete source code as you receive it, in any medium, provided that > you conspicuously and appropriately publish on each copy an > appropriate copyright notice and disclaimer of warranty; keep intact > all the notices that refer to this License and to the absence of any > warranty; and distribute a copy of this License along with the > Library. > > You may charge a fee for the physical act of transferring a copy, > and you may at your option offer warranty protection in exchange for a > fee. > > 2. You may modify your copy or copies of the Library or any portion > of it, thus forming a work based on the Library, and copy and > distribute such modifications or work under the terms of Section 1 > above, provided that you also meet all of these conditions: > > a) The modified work must itself be a software library. > > b) You must cause the files modified to carry prominent notices > stating that you changed the files and the date of any change. > > c) You must cause the whole of the work to be licensed at no > charge to all third parties under the terms of this License. > > d) If a facility in the modified Library refers to a function or a > table of data to be supplied by an application program that uses > the facility, other than as an argument passed when the facility > is invoked, then you must make a good faith effort to ensure that, > in the event an application does not supply such function or > table, the facility still operates, and performs whatever part of > its purpose remains meaningful. > > (For example, a function in a library to compute square roots has > a purpose that is entirely well-defined independent of the > application. Therefore, Subsection 2d requires that any > application-supplied function or table used by this function must > be optional: if the application does not supply it, the square > root function must still compute square roots.) > > These requirements apply to the modified work as a whole. If > identifiable sections of that work are not derived from the Library, > and can be reasonably considered independent and separate works in > themselves, then this License, and its terms, do not apply to those > sections when you distribute them as separate works. But when you > distribute the same sections as part of a whole which is a work based > on the Library, the distribution of the whole must be on the terms of > this License, whose permissions for other licensees extend to the > entire whole, and thus to each and every part regardless of who wrote > it. > > Thus, it is not the intent of this section to claim rights or contest > your rights to work written entirely by you; rather, the intent is to > exercise the right to control the distribution of derivative or > collective works based on the Library. > > In addition, mere aggregation of another work not based on the Library > with the Library (or with a work based on the Library) on a volume of > a storage or distribution medium does not bring the other work under > the scope of this License. > > 3. You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. To do > this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version 2, > instead of to this License. (If a newer version than version 2 of the > ordinary GNU General Public License has appeared, then you can specify > that version instead if you wish.) Do not make any other change in > these notices. > > Once this change is made in a given copy, it is irreversible for > that copy, so the ordinary GNU General Public License applies to all > subsequent copies and derivative works made from that copy. > > This option is useful when you wish to copy part of the code of > the Library into a program that is not a library. > > 4. You may copy and distribute the Library (or a portion or > derivative of it, under Section 2) in object code or executable form > under the terms of Sections 1 and 2 above provided that you accompany > it with the complete corresponding machine-readable source code, which > must be distributed under the terms of Sections 1 and 2 above on a > medium customarily used for software interchange. > > If distribution of object code is made by offering access to copy > from a designated place, then offering equivalent access to copy the > source code from the same place satisfies the requirement to > distribute the source code, even though third parties are not > compelled to copy the source along with the object code. > > 5. A program that contains no derivative of any portion of the > Library, but is designed to work with the Library by being compiled or > linked with it, is called a "work that uses the Library". Such a > work, in isolation, is not a derivative work of the Library, and > therefore falls outside the scope of this License. > > However, linking a "work that uses the Library" with the Library > creates an executable that is a derivative of the Library (because it > contains portions of the Library), rather than a "work that uses the > library". The executable is therefore covered by this License. > Section 6 states terms for distribution of such executables. > > When a "work that uses the Library" uses material from a header file > that is part of the Library, the object code for the work may be a > derivative work of the Library even though the source code is not. > Whether this is true is especially significant if the work can be > linked without the Library, or if the work is itself a library. The > threshold for this to be true is not precisely defined by law. > > If such an object file uses only numerical parameters, data > structure layouts and accessors, and small macros and small inline > functions (ten lines or less in length), then the use of the object > file is unrestricted, regardless of whether it is legally a derivative > work. (Executables containing this object code plus portions of the > Library will still fall under Section 6.) > > Otherwise, if the work is a derivative of the Library, you may > distribute the object code for the work under the terms of Section 6. > Any executables containing that work also fall under Section 6, > whether or not they are linked directly with the Library itself. > > 6. As an exception to the Sections above, you may also combine or > link a "work that uses the Library" with the Library to produce a > work containing portions of the Library, and distribute that work > under terms of your choice, provided that the terms permit > modification of the work for the customer's own use and reverse > engineering for debugging such modifications. > > You must give prominent notice with each copy of the work that the > Library is used in it and that the Library and its use are covered by > this License. You must supply a copy of this License. If the work > during execution displays copyright notices, you must include the > copyright notice for the Library among them, as well as a reference > directing the user to the copy of this License. Also, you must do one > of these things: > > a) Accompany the work with the complete corresponding > machine-readable source code for the Library including whatever > changes were used in the work (which must be distributed under > Sections 1 and 2 above); and, if the work is an executable linked > with the Library, with the complete machine-readable "work that > uses the Library", as object code and/or source code, so that the > user can modify the Library and then relink to produce a modified > executable containing the modified Library. (It is understood > that the user who changes the contents of definitions files in the > Library will not necessarily be able to recompile the application > to use the modified definitions.) > > b) Use a suitable shared library mechanism for linking with the > Library. A suitable mechanism is one that (1) uses at run time a > copy of the library already present on the user's computer system, > rather than copying library functions into the executable, and (2) > will operate properly with a modified version of the library, if > the user installs one, as long as the modified version is > interface-compatible with the version that the work was made with. > > c) Accompany the work with a written offer, valid for at > least three years, to give the same user the materials > specified in Subsection 6a, above, for a charge no more > than the cost of performing this distribution. > > d) If distribution of the work is made by offering access to copy > from a designated place, offer equivalent access to copy the above > specified materials from the same place. > > e) Verify that the user has already received a copy of these > materials or that you have already sent this user a copy. > > For an executable, the required form of the "work that uses the > Library" must include any data and utility programs needed for > reproducing the executable from it. However, as a special exception, > the materials to be distributed need not include anything that is > normally distributed (in either source or binary form) with the major > components (compiler, kernel, and so on) of the operating system on > which the executable runs, unless that component itself accompanies > the executable. > > It may happen that this requirement contradicts the license > restrictions of other proprietary libraries that do not normally > accompany the operating system. Such a contradiction means you cannot > use both them and the Library together in an executable that you > distribute. > > 7. You may place library facilities that are a work based on the > Library side-by-side in a single library together with other library > facilities not covered by this License, and distribute such a combined > library, provided that the separate distribution of the work based on > the Library and of the other library facilities is otherwise > permitted, and provided that you do these two things: > > a) Accompany the combined library with a copy of the same work > based on the Library, uncombined with any other library > facilities. This must be distributed under the terms of the > Sections above. > > b) Give prominent notice with the combined library of the fact > that part of it is a work based on the Library, and explaining > where to find the accompanying uncombined form of the same work. > > 8. You may not copy, modify, sublicense, link with, or distribute > the Library except as expressly provided under this License. Any > attempt otherwise to copy, modify, sublicense, link with, or > distribute the Library is void, and will automatically terminate your > rights under this License. However, parties who have received copies, > or rights, from you under this License will not have their licenses > terminated so long as such parties remain in full compliance. > > 9. You are not required to accept this License, since you have not > signed it. However, nothing else grants you permission to modify or > distribute the Library or its derivative works. These actions are > prohibited by law if you do not accept this License. Therefore, by > modifying or distributing the Library (or any work based on the > Library), you indicate your acceptance of this License to do so, and > all its terms and conditions for copying, distributing or modifying > the Library or works based on it. > > 10. Each time you redistribute the Library (or any work based on the > Library), the recipient automatically receives a license from the > original licensor to copy, distribute, link with or modify the Library > subject to these terms and conditions. You may not impose any further > restrictions on the recipients' exercise of the rights granted herein. > You are not responsible for enforcing compliance by third parties with > this License. > > 11. If, as a consequence of a court judgment or allegation of patent > infringement or for any other reason (not limited to patent issues), > conditions are imposed on you (whether by court order, agreement or > otherwise) that contradict the conditions of this License, they do not > excuse you from the conditions of this License. If you cannot > distribute so as to satisfy simultaneously your obligations under this > License and any other pertinent obligations, then as a consequence you > may not distribute the Library at all. For example, if a patent > license would not permit royalty-free redistribution of the Library by > all those who receive copies directly or indirectly through you, then > the only way you could satisfy both it and this License would be to > refrain entirely from distribution of the Library. > > If any portion of this section is held invalid or unenforceable under any > particular circumstance, the balance of the section is intended to apply, > and the section as a whole is intended to apply in other circumstances. > > It is not the purpose of this section to induce you to infringe any > patents or other property right claims or to contest validity of any > such claims; this section has the sole purpose of protecting the > integrity of the free software distribution system which is > implemented by public license practices. Many people have made > generous contributions to the wide range of software distributed > through that system in reliance on consistent application of that > system; it is up to the author/donor to decide if he or she is willing > to distribute software through any other system and a licensee cannot > impose that choice. > > This section is intended to make thoroughly clear what is believed to > be a consequence of the rest of this License. > > 12. If the distribution and/or use of the Library is restricted in > certain countries either by patents or by copyrighted interfaces, the > original copyright holder who places the Library under this License may add > an explicit geographical distribution limitation excluding those countries, > so that distribution is permitted only in or among countries not thus > excluded. In such case, this License incorporates the limitation as if > written in the body of this License. > > 13. The Free Software Foundation may publish revised and/or new > versions of the Lesser General Public License from time to time. > Such new versions will be similar in spirit to the present version, > but may differ in detail to address new problems or concerns. > > Each version is given a distinguishing version number. If the Library > specifies a version number of this License which applies to it and > "any later version", you have the option of following the terms and > conditions either of that version or of any later version published by > the Free Software Foundation. If the Library does not specify a > license version number, you may choose any version ever published by > the Free Software Foundation. > > 14. If you wish to incorporate parts of the Library into other free > programs whose distribution conditions are incompatible with these, > write to the author to ask for permission. For software which is > copyrighted by the Free Software Foundation, write to the Free > Software Foundation; we sometimes make exceptions for this. Our > decision will be guided by the two goals of preserving the free status > of all derivatives of our free software and of promoting the sharing > and reuse of software generally. > > NO WARRANTY > > 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO > WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. > EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR > OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY > KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE > IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE > LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME > THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. > > 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN > WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY > AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU > FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR > CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE > LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING > RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A > FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF > SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH > DAMAGES. > > END OF TERMS AND CONDITIONS > > How to Apply These Terms to Your New Libraries > > If you develop a new library, and you want it to be of the greatest > possible use to the public, we recommend making it free software that > everyone can redistribute and change. You can do so by permitting > redistribution under these terms (or, alternatively, under the terms of the > ordinary General Public License). > > To apply these terms, attach the following notices to the library. It is > safest to attach them to the start of each source file to most effectively > convey the exclusion of warranty; and each file should have at least the > "copyright" line and a pointer to where the full notice is found. > > > Copyright (C) > > This library is free software; you can redistribute it and/or > modify it under the terms of the GNU Lesser General Public > License as published by the Free Software Foundation; either > version 2.1 of the License, or (at your option) any later version. > > This library is distributed in the hope that it will be useful, > but WITHOUT ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > Lesser General Public License for more details. > > You should have received a copy of the GNU Lesser General Public > License along with this library; if not, write to the Free Software > Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > > Also add information on how to contact you by electronic and paper mail. > > You should also get your employer (if you work as a programmer) or your > school, if any, to sign a "copyright disclaimer" for the library, if > necessary. Here is a sample; alter the names: > > Yoyodyne, Inc., hereby disclaims all copyright interest in the > library `Frob' (a library for tweaking knobs) written by James Random Hacker. > > , 1 April 1990 > Ty Coon, President of Vice > > That's all there is to it! > ------------------------ end of proposed license ------------------ > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From gjhanna at gmail.com Sun Mar 11 14:21:17 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Mon, 12 Mar 2007 09:21:17 +1300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hi Pavel, We are using RXTX under VMWare server in production, quite satisfactorily. We're using Red Hat Enterprise Server 4, and ... Whatever the "enterprise" VMWare product is. Regards, Greg H > Subject: [Rxtx] RXTX under VMWare server > To: rxtx at qbang.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. [ ... snip ... ] -- Pavel Parkhomenko -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070311/4cebb6f9/attachment-0003.html From gergg at cox.net Sun Mar 11 23:39:19 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 12 Mar 2007 00:39:19 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: <45F4E787.6050502@cox.net> Trent Jarvi wrote: > I can start going through the method interfaces later this week and giving > feedback. I would suggest that the JSR should not be too generic in > nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel > drivers that intend to look like EIA232 ports at the kernel driver level. > > some ideas: > > EIA232PortInterface > TermiosInterface > SerialPortInterface > > Something that differentiates this from thing like USB, I2C, ... which > should not have to deal with legacy serial claiming to be the comm api. I'm going to throw out a suggestion, which I am mostly serious about. What would happen if we took the appropriate bits of the J2ME connector API, and just used that as the new COMM API so that finally JSE and JME had a common foundation for these kinds of things? Gregg Wonderly From ra85551 at gmail.com Mon Mar 12 09:08:37 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Mon, 12 Mar 2007 18:08:37 +0300 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Should any application use the modem, HyperTerminal won't be able to talk to the modem. But it actually can send and receive AT comands, while my application cannot :-( > Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Thansk for the reference. I examined that example and found that there's no significant differences between my read/write implementation and that one, except that SimpleSnuV1 listens for serialEvent's, but not for sake of data retrieval, just for printing them out - I don't know why ;-) > Note that modems could care less what OS is on top. If you are trying to > match new lines to the OS and sending it to the mode for AT commands, > thats probably a mistake. I do send strings to serial port, not to OS, and do try to get answers back. If it is the mistake, what's the right way? > Also it would not hurt to print out the > individual bytes that you are sending to make sure they did not get > mangled along the path. Yeah, I am printing these bytes before doing write, but it means that I only see what I intend to write. How can I ensure that these bytes have gone out of the box and reached my modem? BTW, I found that my send/receive method is complex enough, so I've rewritten it. Please, see the following code and point any mistakes, because I don't know where can they remain yet. private static final int LARGE_TIMEOUT = 15000; private static final int SMALL_TIMEOUT = 500; ... private String sendATCommand(String command, String waitFor, boolean isRegex, boolean isAddCRLF) throws BeaconConnectException { byte[] buffer = new byte[512]; int offset; String result = ""; try { if (waitFor != null) { serialPort.enableReceiveTimeout(LARGE_TIMEOUT); } else { serialPort.enableReceiveTimeout(SMALL_TIMEOUT); } if (command != null) { OutputStream serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } offset = 0; InputStream serialInput = serialPort.getInputStream(); while (serialInput.available() != -1) { int bytesRead = serialInput.read(buffer, offset, buffer.length - offset); if (bytesRead == 0) { break; } offset += bytesRead; result = new String(buffer, 0, offset).trim(); if (waitFor != null) { System.out.println(result); if (isRegex && result.matches(waitFor) || result.contains(waitFor)) { break; } } } } catch (UnsupportedCommOperationException e) { throw new MyException("unsupported operation"); } catch (IOException e) { throw new MytException("serial I/O error"); } return result; } -- Pavel Parkhomenko From clayno at hotpop.com Thu Mar 15 02:47:34 2007 From: clayno at hotpop.com (Christopher Layno) Date: Thu, 15 Mar 2007 16:47:34 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi, we're using the latest release of rxtx (2.1-7r2) for our system that has two applications using the library. one application sends requests to the modem while the other simply checks the modem status. we deployed our system on a pentium machine with red hat linux 9.0 installed. now the problem arises when these two applications try to access the same modem at the same time. one of them will eventually have to throw the PortInUseException as shown below: 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException gnu.io.PortInUseException: root PID = 743 Program = java root PID = 743 Program = java root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) this was expected. what we didn't expect though was that if we repeat the scenario 5 times, always 5 times, the application would also throw a VM error: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4473CD21 Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so Current Java thread: at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) - locked <0x44cfd4c8> (a gnu.io.CommPortIdentifier) at ************ at ************ - locked <0x4476a468> (a **********) at ************ at ************ at ************ at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java :261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages( TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run( TCPTransport.java:701) at java.lang.Thread.run(Thread.java:534) note: i replaced some sensitive data with asterisks our team has looked everywhere on the internet, including your mail archives, for a solution to this problem but to no avail. i really hope you could help us out on this one. thanks in advance! best regards, chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070315/1936460a/attachment-0003.html From tjarvi at qbang.org Fri Mar 16 04:30:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 04:30:25 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: On Thu, 15 Mar 2007, Christopher Layno wrote: > hi, > > we're using the latest release of rxtx (2.1-7r2) for our system that has two > applications using the library. one application sends requests to the modem > while the other simply checks the modem status. we deployed our system on a > pentium machine with red hat linux 9.0 installed. > > now the problem arises when these two applications try to access the same > modem at the same time. one of them will eventually have to throw the > PortInUseException as shown below: > > 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException > gnu.io.PortInUseException: root PID = 743 Program = java root PID = > 743 Program = java root PID = 743 Program = ??? root PID = 743 Program > = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root > PID = 743 Program = ??? root PID = 743 Program = ??? > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > > this was expected. what we didn't expect though was that if we repeat the > scenario 5 times, always 5 times, the application would also throw a VM > error: > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x4473CD21 > Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 > Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so > > Current Java thread: > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) Hi Chris The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. The code is originally by Werner Almesberger. He gave us permission to use it in rxtx. You might look at what has changed since 1998 in his fuser application. Or you can just do like other OSs and do the following in fuserImp.c JNIEXPORT jstring JNICALL Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv *env, jobject obj, jstring arg) { return (*env)->NewStringUTF(env, "Unknown Application"); } It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. -- Trent Jarvi tjarvi at qang.org From Adrien.TOS at ingenico.com Fri Mar 16 05:11:12 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Fri, 16 Mar 2007 12:11:12 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903CBC312@frsnprexc1.usr.ingenico.loc> Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070316/972ab214/attachment-0003.html From joachim at buechse.de Fri Mar 16 05:13:24 2007 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 16 Mar 2007 12:13:24 +0100 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. From tjarvi at qbang.org Fri Mar 16 16:36:29 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 16:36:29 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Fri Mar 16 16:02:23 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 16 Mar 2007 18:02:23 -0400 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Not all platforms are Unix based. Also mixing native library usage and command-line calls is not an elegant solution, IMHO. One or the other, but not both. Andre On 16-Mar-07, at 07:13 , Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is > trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We >> only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From clayno at hotpop.com Sun Mar 18 22:17:28 2007 From: clayno at hotpop.com (Christopher Layno) Date: Mon, 19 Mar 2007 12:17:28 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi everyone, thank you so much for your replies. they were really helpful. anyway, before i sent the email, my team was already implementing a temporary solution by using joachim's suggestion. we invoked a lsof command from our java code although i share the same concern with trent and andre-john about portability issues. that's why i said it's just temporary. my superiors have yet to approve our bug fix. so my question now is this: is recompiling the rxtx source code the only way to solve this problem? because if it's the only solution, then i think my superiors would rather have a new release from the rxtx community itself that fixes this bug(?) rather than have my team recompile the source code. best regards, chris Trent Jarvi wrote: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. ... It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070318/237463b2/attachment-0003.html From tjarvi at qbang.org Mon Mar 19 16:20:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Mar 2007 16:20:52 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: Hi Chris I can compile a new version after the 21st if you do not feel comfortable doing so. Please send me an email reminder off-line then. On Mon, 19 Mar 2007, Christopher Layno wrote: > hi everyone, > > thank you so much for your replies. they were really helpful. > > anyway, before i sent the email, my team was already implementing a > temporary solution by using joachim's suggestion. > we invoked a lsof command from our java code although i share the same > concern with trent and andre-john about > portability issues. that's why i said it's just temporary. my superiors have > yet to approve our bug fix. > > so my question now is this: is recompiling the rxtx source code the only way > to solve this problem? because if it's the only > solution, then i think my superiors would rather have a new release from the > rxtx community itself that fixes this bug(?) > rather than have my team recompile the source code. > > best regards, > > chris > > Trent Jarvi wrote: > > Hi Joachim > > It would be nice to have that functionality but calling the program > introduces too many issues imho. Explaining to someone why rxtx invoked a > rogue lsof does not sound very interesting. > > On Fri, 16 Mar 2007, Joachim Buechse wrote: > > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: > > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. > > _______________________________________________ > Rxtx mailing list > Rxtx 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 Eric.Arseneau at sun.com Tue Mar 20 11:47:33 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Tue, 20 Mar 2007 10:47:33 -0700 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 Message-ID: <46001E35.9040608@sun.com> Anyone have any experience with RXTX working with JDK 6 on other platforms ? From mm at UDel.Edu Tue Mar 20 12:18:29 2007 From: mm at UDel.Edu (Mike Markowski) Date: Tue, 20 Mar 2007 14:18:29 -0400 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 In-Reply-To: <46001E35.9040608@sun.com> References: <46001E35.9040608@sun.com> Message-ID: <46002575.4000306@udel.edu> Eric Arseneau wrote: > Anyone have any experience with RXTX working with JDK 6 on other platforms ? I'm using 32 bit intel, gentoo linux, jdk6 with no problems. My applications only use a serial port, though, nothing on the parallel port. Mike From falko.guderian at gmx.de Wed Mar 21 08:17:35 2007 From: falko.guderian at gmx.de (Falko Guderian) Date: Wed, 21 Mar 2007 15:17:35 +0100 Subject: [Rxtx] RXTX binaries for SH4 Message-ID: <46013E7F.40102@gmx.de> Dear developers, I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no possiblities to compile the source code. Better, I'm not able to do this at the moment. Can you provide me with rxtxSerial.dll (SH4) in the rxtx-2.1-8-testing version? (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) The reason for the testing version is I need custom baud rates. Thanks for help. Kind regards, Falko Guderian From tjarvi at qbang.org Wed Mar 21 21:38:37 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Mar 2007 21:38:37 -0600 (MDT) Subject: [Rxtx] RXTX binaries for SH4 In-Reply-To: <46013E7F.40102@gmx.de> References: <46013E7F.40102@gmx.de> Message-ID: On Wed, 21 Mar 2007, Falko Guderian wrote: > Dear developers, > > I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no > possiblities to compile the source code. Better, I'm not able to do this > at the moment. Can you provide me with rxtxSerial.dll (SH4) in the > rxtx-2.1-8-testing version? > (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) > > The reason for the testing version is I need custom baud rates. > > Thanks for help. > Hi Falko WinCE binary format is not supported by gcc. That makes compiling limited to those familiar with the WinCE tools. I hope someone is able to provide them for you but it is not likely. WinCE has been compiled by others in the past but rxtx.org builds have never included WinCE. There is some information with the source concerning WinCE builds if you decide to do it. We can share your results too if you like. The source in the WinCE has never been updated for the custom baud rate. That would need changes from the main source I presume. If you look at the source, you will note that Michal Hobot created a mini fork in the source to handle wince but it has not been updated for 3 years. -- Trent Jarvi tjarvi at qbang.org From Adrien.TOS at ingenico.com Thu Mar 22 07:08:55 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Thu, 22 Mar 2007 14:08:55 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Hi everybody, Do you have any comments on this issue? Thanks! AT ________________________________ De : Adrien TOS Envoy? : vendredi 16 mars 2007 12:11 ? : 'rxtx at qbang.org' Cc : Adrien TOS Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070322/2306c538/attachment-0003.html From jeremy.reeve at zen.co.uk Mon Mar 19 07:36:04 2007 From: jeremy.reeve at zen.co.uk (Jeremy S. Reeve) Date: Mon, 19 Mar 2007 13:36:04 +0000 Subject: [Rxtx] rxtx failing to compile on Fedora Core 6 Message-ID: <1174311364.21865.6.camel@d9thc> When trying to compile latest source : rxtx-2.1-7r2 I get the following when running configure: ---------------- checking os.version 2.6.18-1.2200.fc5smp WARNING: configure is having a hard time determining which directory contains the file jni_md.h. Edit Makefile and fix the variable JAVANATINC to point to the correct directory. The following options are available: /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/ /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/linux/ If there are more than one option available the first was selected. WARNING: Kernel include files do not match the current kernel configure: creating ./config.status ------------------------ which seems OK checking the resultant Makefile but when attempting to build with gmake install I get the following output : ---------------------- 34 problems (34 warnings)/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/javah -classpath .:/home/jsr/rxtxsrc/rxtx-2.1-7r2:/home/jsr/rxtxsrc/rxtx-2.1-7r2/src:/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/ext/RXTXcomm.jar -d i686-pc-linux-gnu -jni `(for i in CommDriver CommPortEnumerator CommPortIdentifier CommPort CommPortOwnershipListener Configure I2C I2CPortEvent I2CPortEventListener I2CPort LPRPort NoSuchPortException ParallelPortEvent ParallelPortEventListener ParallelPort PortInUseException Raw RawPortEvent RawPortEventListener RawPort RS485 RS485PortEvent RS485PortEventListener RS485Port RXTXCommDriver RXTXPort RXTXVersion SerialPortEvent SerialPortEventListener SerialPort UnsupportedCommOperationException UnSupportedLoggerException Zystem;do \ if grep > /dev/null native.* \( /home/jsr/rxtxsrc/rxtx-2.1-7r2/./src/$i.java; then \ echo gnu.io.$i; \ fi; \ done)` i686-pc-linux-gnu/gnu_io_CommPortIdentifier.h: No such file or directory make: *** [/home/jsr/rxtxsrc/rxtx-2.1-7r2/gnu/io/CommDriver.class] Error 1 ------------------------ Any ideas or pointers? Regards, Jeremy From tjarvi at qbang.org Sat Mar 24 08:12:54 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 Mar 2007 08:12:54 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > From Adrien.TOS at ingenico.com Sat Mar 24 11:53:22 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Sat, 24 Mar 2007 18:53:22 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> I do not have the threshold setting enabled, I have explicitely disabled it with: port_.disableReceiveThreshold(); I have also run the same tests with the threshold setting enabled, but they also fail in the same way as described below. So it seems there is a problem with timeout handling on Win32? ________________________________ From: rxtx-bounces at qbang.org on behalf of Trent Jarvi Sent: Sat 3/24/2007 3:12 PM To: RXTX Developers and Users Subject: Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 8312 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20070324/f9e39c9b/attachment-0003.bin From greg.johnson at manchester.ac.uk Sun Mar 25 13:41:36 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Sun, 25 Mar 2007 21:41:36 +0200 Subject: [Rxtx] Mac intel weirdness Message-ID: Hi folks, I'm trying to get rxtx to work on my macbook pro with a USB-serial dongle on it. I am using the 2.1-8 code from the CVS (though it seems to report itself as 2.1-7: makes it difficult to prove to oneself that the changes have 'taken'! - line 4210 in SerialImp.c, line 40 in RXTXVersion.java) I am trying the 2.1-8 because of horrible lock problems in 2.1-7. However, the serialport closure code seems to be broken - it won't close because it believes the (previously opened!) port doesn't exist. Here is what I'm trying: 0. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "false" 1. Open a port Serialport serialport = (SerialPort) commportidentifier.open ("test",100); 2. Talk to a device ... 3. Close port serialport.close(); 4. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "true" - why is this? 5. Try to reopen port Serialport serialport2 = (SerialPort) commportidentifier.open("test", 100); throws PortInUseException. I've dug around a bit in the source, and it seems the SerialPort.close () should call the CommPortIdentifier.internalClosePort() (line 67 of CommPort.java). However, I crash out with the NoSuchPortException when getPortIdentifier is called. Which seems quite weird to me, seeing as it is called on this - which was create just beforehand. Does anyone know how to fix this? Cheers, greg From knute at frazmtn.com Sat Mar 24 10:32:38 2007 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 24 Mar 2007 09:32:38 -0700 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc>, Message-ID: <4604F036.17833.135298@knute.frazmtn.com> > >The behavior of timeout depends upon the setting of the threshold. Do you >have the threshold setting? > This is the same bug I reported last fall. There was a fellow that sent me an email asking if it had been fixed. I told him I didn't think so. He got somebody to write a fix for him but I have not been able to contact him again for the actual changes. The inaccurate timeout and the failure of blocking when no timeouts are set is a serious bug in my humble opinion and renders the software unusable for my applications. I'd really like to have an alternative to the Sun comm api but there just isn't one that I know of. -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Mar 26 16:17:00 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 26 Mar 2007 16:17:00 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> Message-ID: >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. From ra85551 at gmail.com Tue Mar 27 10:18:36 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Tue, 27 Mar 2007 20:18:36 +0400 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Ultimately I found a solution. At first, that wasn't actually the VMWare + WinXP + RXTX issue, that was WinXP + RXTX issue. But on pure XP it sometimes workes, sometimes not, while under VMWare I had never seen my snippet working at all. SimpleSnuV1.java would not help me, because there is only one line I missed, and SimpleSnuV1.java also doesn't contain it! It is as follows: serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_OUT | SerialPort.FLOWCONTROL_RTSCTS_IN); Thank you for your attention. -- Pavel Parkhomenko From griff at op.pl Wed Mar 28 01:28:19 2007 From: griff at op.pl (griff@op.pl) Date: Wed, 28 Mar 2007 09:28:19 +0200 Subject: [Rxtx] No blocking read on Windows. Message-ID: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/5d07d571/attachment-0003.html -------------- next part -------------- Hi, I have problem that InputStram.read() (SerialPort)?returns -1 instead blocking and waiting for data. I found that this problem was ?known in 2005 : ? >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > >> Hi Trent >> >> Thanks for the fast response. >> Here's a Q&D test program for the blocking read on windows that just >> attempts to read one byte, and prints the resulting byte. On my system it >> returns -1, where I expect that it keeps waiting for data. >> >This isn't happening on Linux so the bug is in src/termios.c.? I'll have >something this weekend to fix that. I'm using RXTX 2.1.7r2 and the problem still is here. Im using Windows XP and java 1.5 disableReciveTimeout() and disableReciveTreshhold() dont help. ? best regards ? Piotr Zielniok From Adrien.TOS at ingenico.com Wed Mar 28 01:40:46 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Wed, 28 Mar 2007 09:40:46 +0200 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903E88880@frsnprexc1.usr.ingenico.loc> Looking at the code, it seems there is no support for infinite timeout? And maybe the count++ < 20 condition is breaking out of the loop too early? The only condition to break out of the loop should either be the timeout has expired or the number of requested bytes has been received. -----Message d'origine----- De : rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] De la part de Trent Jarvi Envoy? : mardi 27 mars 2007 00:17 ? : RXTX Developers and Users Objet : Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From j.kenneth.gentle at acm.org Wed Mar 28 06:44:15 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 28 Mar 2007 08:44:15 -0400 Subject: [Rxtx] No blocking read on Windows. In-Reply-To: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> References: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> Message-ID: <200703281844.l2SIiITW028614@qbang.org> Just another "ME TOO!" - I'm seeing this problem on Windows XP, jre for windows XP/Embedded. I cranked receiveTimeout up to Integer.MAX_INT, but it doesn't seem to wait that long At 03:28 2007-03-28, you wrote: >Hi, >I have problem that InputStram.read() (SerialPort) returns -1 >instead blocking and waiting for data. I found that this problem >was known in 2005 : > > >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > > > >> Hi Trent > >> > >> Thanks for the fast response. > >> Here's a Q&D test program for the blocking read on windows that just > >> attempts to read one byte, and prints the resulting byte. On my system it > >> returns -1, where I expect that it keeps waiting for data. > >> > > >This isn't happening on Linux so the bug is in src/termios.c. I'll have > >something this weekend to fix that. > >I'm using RXTX 2.1.7r2 and the problem still is here. >Im using Windows XP and java 1.5 >disableReciveTimeout() and disableReciveTreshhold() dont help. > >best regards > >Piotr Zielniok > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From greg.johnson at manchester.ac.uk Wed Mar 28 14:43:29 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Wed, 28 Mar 2007 22:43:29 +0200 Subject: [Rxtx] Cannot close and reopen serial port Message-ID: <377F9765-7A9D-4CE9-9176-FFB63A2594F0@manchester.ac.uk> Dear all, It appears I cannot close a port properly: SerialPort serialport = portid.open("myprog",100); // do some stuff, all works fine serialport.close(); // all seems fine but... SerialPort sp2 = portid.open("myprog",100); throws PortInUseException. And when I dig into the rxtx code, I find in CommPort.java, in close(): CommPortIdentifier cp = CommPortIdentifier.getPortIdentifier(this); (line 64 or there abouts) but this throws a NoSuchPortException which is caught but ignored (line 74ish). Can anyone suggest how this could happen: a port that was valid, opened, and used, throws a NSPE when it comes to closing it? I'm pulling my (remaining) hair out over this one! Cheers, greg PS And thanks for RXTX - it's great to have! PPS (21.-7. winxp/osx both, java 1.5) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/c28852fc/attachment-0003.html From rxtx at vrijheidslaan.net Fri Mar 30 16:52:50 2007 From: rxtx at vrijheidslaan.net (Rob) Date: Fri, 30 Mar 2007 22:52:50 -0000 Subject: [Rxtx] Cvs Question Message-ID: <61896.80.126.150.87.1175295162.squirrel@webmail.provalue.nl> Hi There, Im trying to get the latest version to work on mac osx. Problem is that i can't checkout version 2.1.8. Probably my fault but can some one please give me the alternative commands for: [user at myhost]$ export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot [user at myhost]$ cvs login Thanx, Rob From ra85551 at gmail.com Thu Mar 1 03:47:06 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Thu, 1 Mar 2007 13:47:06 +0300 Subject: [Rxtx] enableReceiveTimeout() issue Message-ID: Hello, world! I found a limitation of 16300 ms for CommPort's enableReceiveTimeout() method, while in original javax.comm docs there are no any references to that. Is that a bug or feature? I actually need longer timeouts sometimees. -- Pavel Parkhomenko From lyon at docjava.com Thu Mar 1 07:54:17 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 01 Mar 2007 09:54:17 -0500 Subject: [Rxtx] parametric singleton design pattern In-Reply-To: References: <22d55aea0702081207q5e7f6785l352d498d6f5f9fb1@mail.gmail.com> <22d55aea0702100034o3bcf42f3j1d1a6257029a67b0@mail.gmail.com> Message-ID: Hi All, I have been thinking about the use of a design pattern to cache resources that are consumed by processes. Toward that end, I have arrived at a parametric singleton design pattern, which I mentioned on this list some time ago. The idea has been published at: http://www.jot.fm/issues/issue_2007_03/column2 I can't help but think that there should be an API available for dealing with the tracking of serial port usage. Perhaps it is a kind of resource manager called the: SerialPortManager basic prototypes already exist in this vain. See, for example: http://www.ce.rit.edu/research/projects/2005_fall/rt_poolsystem/doc/PoolMon/SerialPortManager.html http://www.eventhelix.com/RealtimeMantra/PatternCatalog/serial_port_design_pattern.htm And others shown by a google search on "SerialPortManager" Cheers! - Doug From Eric.Arseneau at sun.com Thu Mar 1 10:15:03 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:15:03 -0800 Subject: [Rxtx] Any known Java 6 issues with RXTX 2.1-7r2 ? Message-ID: <45E70A17.1060206@sun.com> I just did a test on a recent build of Solaris 11 x86 and it seems that I can connect to my serial device fine when Java 5 is the default, but when Java 6 is the default, no go. Any information ? From Eric.Arseneau at sun.com Thu Mar 1 10:19:58 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:19:58 -0800 Subject: [Rxtx] Mac OS X and missing data Message-ID: <45E70B3E.7040908@sun.com> We have a device which is USB based but presents itself as a serial port to a machine. On my MacBook Pro I can get excellent throughput if I get my device to send data as quickly as possible. On the desktop side, if I do an type of disk IO to log the data I get, I end up with some missing data at some point. I hooked up a USB analyzer and did confirm that all the data is sent as expected to the desktop from the device. I found a work around for this, buffer the data in memory and only write the data out when I've received it all. However, when the same code and same device is attempted on a co-workers MacBook Pro (same hardware specs), I get errors and must slow down dramatically the device side's sending of data. Any ideas/recommendations on what I can do to get rid of this error ? From what I can tell, it seems that RXTX is not able to wake up to the interrupts coming in indicating data is ready, quickly enough, is there anything I can do ? From chinkaiw at hotmail.com Fri Mar 2 00:57:43 2007 From: chinkaiw at hotmail.com (Wang Chinkai) Date: Fri, 02 Mar 2007 07:57:43 +0000 Subject: [Rxtx] dynamic detect rs232 port Message-ID: Hi all I have a question about detecting rs232 port dynamicly. I have to aceess some port and detect rs232 port at the same time. Some usb device simulates rs232 port , and I can not know what the port name it gets until it connects,so I have to detect it dynamic,but I have to access another rs232 device at the same time. I found a problem. If I use CommPortIdentifier.getPortIdentifiers() to get new port list , and the other rs232 access function will not close port correctly. So , How can I solve it . Thanks. _________________________________________________________________ ?? 2GB ???? Windows Live Mail ????????????? http://ideas.live.com/programpage.aspx?versionid=5d21c51a-b161-4314-9b0e-4911fb2b2e6d From eu259473 at tele2.it Fri Mar 2 06:16:40 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 02 Mar 2007 14:16:40 +0100 Subject: [Rxtx] rxtx on HP tru 64 unix Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070302/706c7a70/attachment-0004.html From tjarvi at qbang.org Fri Mar 2 08:39:33 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 08:39:33 -0700 (MST) Subject: [Rxtx] rxtx on HP tru 64 unix In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, "Giuseppe Marchese" wrote: > Hi > > I try to install rxtx on hp tru 64 but make fails, > There are somebody that do the same and work. > > > Sorry for may english! > > Hi Giuseppe Could you provide a log of the failure? script ./configure make # use gnu make exit The information will be in the typescript created. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 2 19:56:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 19:56:52 -0700 (MST) Subject: [Rxtx] dynamic detect rs232 port In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, Wang Chinkai wrote: > Hi all > > I have a question about detecting rs232 port dynamicly. > > I have to aceess some port and detect rs232 port at the same time. > Some usb device simulates rs232 port , and I can not know > what the port name it gets until it connects,so I have to detect it > dynamic,but I have to access > another rs232 device at the same time. > > I found a problem. Hi Wang This is a known problem. The code is braindead there. In fact there needs to be events even in a rudamentary way when you add a usb dongle. I'm burried in tasks not far from rxtx but not in rxtx. I can't get to the problem but we would accept patches if you dig into it. [I'm getting to the license question earlier too; I don't have another 10%] -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Fri Mar 2 23:19:01 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 01:19:01 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Hi, Under ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable USB -> serial converter(using virtual com port drivers), with using example code pretty much straight out of http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port opens fine, enumerations all work, etc. My application calls for a large amount of data to be transferred in a short amount of time at 2,000,000 baud. My hardware sends approximately 15,232 bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL converter work fine, and the application works using C++. In C++, I do a hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); to open the port, and a boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); to read the port. The variable buffer fills with the 15238 bytes, and returns. If I do a resultz = is.read(cbuf,0,15238); in java with RXTX where is = new BufferedReader(new InputStreamReader(port.getInputStream())); and where resultz is an int, and cbuf is a char [] cbuf, resultz gets EXACTLY 3968 bytes the first time called. If I call it multiple times, I get roughly 11k total(less than what is sent), never more than the 3968 bytes per is.read() call. My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 bytes. I've played with inputbuffersize, receive threshold, receivetimeout, and so on. The FTDI virtual com port drivers that I'm using are rock solid, and have had zero problems with them using a variety of applications, some of my own, some professionally written, etc. No flow control is used anyplace, no RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. No exceptions are being thrown. What am I doing wrong, and what I can adjust to receive the full 15k bytes in one single read? Thanks! Keith From Eric.Arseneau at sun.com Fri Mar 2 23:32:07 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Fri, 02 Mar 2007 22:32:07 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <45E91667.20501@sun.com> This is the same type of thing that is happening to me on Mac OS X and does not seem to behave the same on different machines. I posted a day or two ago on this with subject "Mac OS X and missing data". Would love to hear if there is a solution to this :) From tjarvi at qbang.org Sat Mar 3 10:54:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 10:54:17 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > Hi, > > Under > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable > USB -> serial converter(using virtual com port drivers), with using example > code pretty much straight out of > http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port > opens fine, enumerations all work, etc. > > My application calls for a large amount of data to be transferred in a short > amount of time at 2,000,000 baud. My hardware sends approximately 15,232 > bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL > converter work fine, and the application works using C++. > > In C++, I do a > > hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, > OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); > > to open the port, and a > > boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); > > to read the port. > > The variable buffer fills with the 15238 bytes, and returns. > > If I do a > > resultz = is.read(cbuf,0,15238); in java with RXTX > > where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > > and where resultz is an int, and cbuf is a char [] cbuf, resultz gets > EXACTLY 3968 bytes the first time called. If I call it multiple times, I get > roughly 11k total(less than what is sent), never more than the 3968 bytes > per is.read() call. > > My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 > bytes. > > I've played with inputbuffersize, receive threshold, receivetimeout, and so > on. The FTDI virtual com port drivers that I'm using are rock solid, and > have had zero problems with them using a variety of applications, some of my > own, some professionally written, etc. No flow control is used anyplace, no > RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. > > No exceptions are being thrown. > > What am I doing wrong, and what I can adjust to receive the full 15k bytes > in one single read? > > Thanks! > Hi Keith I would expect a 20 meg application is going to have different behavior with the OS than a smaller application with respect to the kernel memory managment, schedualing, ... Something subtle could be causing problems. With respect to the recieve timeout and threshold, if you set the timeout to zero and the threshold to the size of data you expect, read should not return until it get that data. You may try with a stand alone application that tests just that with the C/C++ API. If the read is returning with less data when tested for short reads, you have found a bug in the device driver more than likely. The USB dongle vendor would probably be interested in knowing about this. As mentioned, these devices are getting very good; almost bug free. I suspect you found a bug though if you did use the threshold and timeout properly. The missing data is typical when not using flow control. When the OS buffering fills, the hardware will start dropping bytes. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:38:52 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:38:52 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> update: I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now instead of 3968. This makes sense. 128 bytes of overhead + 3968 bytes of data = 4096 transfer size 32 bytes of overhead + 992 bytes of data = 1024 transfer size. 1/4 the data = 1/4 the overhead. I rearranged my reading like so: resultz = is.read(cbuf,0,3968); resultz = is.read(cbuf,3968,3968); resultz = is.read(cbuf,7936,3968); while (!(is.ready())); // wait for ready resultz = is.read(cbuf,11904,3334); and this grabs 15,238 bytes total. BUT, I still have the quandry of the screwed up multi-bytes. I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. Approx 8% of the data. The bad bytes always seem to take the flavor of 0x2018, 0x2019, x2022, x2030, x201d. Are these maybe errors and I don't know what they enumerate to? I still can't believe some other layer isn't handling putting those bytes together all in one stream for me. Thanks Keith ----- Original Message ----- From: "Keith" To: "Bob Jacobsen" ; "RXTX Developers and Users" Sent: Saturday, March 03, 2007 11:26 AM Subject: Re: [Rxtx] is.read() only returning 3968 bytes > Bob, > > > Interesting numerical coincidence is that (max USB transfer) - (what > > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > > needed to transfer that much data. > > I was thinking along the same lines. I don't know USB well, but I do know > that those numbers were close enough to warrant investigating the > relationship between them. > > > I think what you're seeing is the internal buffering of the USB data > > stream. You'll need some form of higher-level buffering to smooth > > that out. > > Shouldn't the InputStreamReader() and BufferedReader() provide this type of > buffering? Isn't that the idea behind those? > > > All hypotheses need to be tested. In this case, a test would be to > > check for missing data. If this idea is right, you'll get _all_ the > > data, but you won't be missing characters. > > I did start looking at the data. -- I'm getting weird results. > > I tried this: > > loopzz = 0; > > for (looptwo = 0; looptwo < 100000; looptwo++) { > while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > > }} > > So I'm reading one character at a time. The good news is that loopzz is > exactly 15238 at the end of the routine, which is perfectly correct. I > picked looptwo value out of thin air. > > The weird results come in terms of the values, the data isn't correct at > least in one case. Look here: > > 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > > This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). > But the 0x89 was replaced by 0x2030. Why the heck would the returned value > be 0x2030?? Why is the returned byte completely out of range? Why the > multibyte return? > > From InputStream in the API: > > read > public abstract int read() > throws IOExceptionReads the next byte of data from the > input stream. The value byte is returned as an int in the range 0 to 255. If > no byte is available because the end of the stream has been reached, the > value -1 is returned. This method blocks until input data is available, the > end of the stream is detected, or an exception is thrown. > Value should be 0-255. > > > In my application time is really critical, reading 1 byte at a time is > probably not going to work. > > Thanks Eric & Bob for looking at this. > > Keith > From tjarvi at qbang.org Sat Mar 3 12:52:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 12:52:27 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > update: > > I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now > instead of 3968. > > This makes sense. > > 128 bytes of overhead + 3968 bytes of data = 4096 transfer size > 32 bytes of overhead + 992 bytes of data = 1024 transfer size. > > 1/4 the data = 1/4 the overhead. > > I rearranged my reading like so: > > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. > Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? > > I still can't believe some other layer isn't handling putting those bytes > together all in one stream for me. > The layer for this in Serial land is flow control. Software and hardware flow control prevent the overruns you observe. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:54:41 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:54:41 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <001a01c75dcd$c8802a70$6600a8c0@jbh757ktruws7g> Trent, Thanks for taking the time to reply. > I would expect a 20 meg application is going to have different behavior > with the OS than a smaller application with respect to the kernel memory > managment, schedualing, ... Something subtle could be causing problems. Well, at least I know the VCP drivers, the OS, etc can handle 2mbps reliably. Without hiccuping or dropping bytes. The C++ code works reliably without flow control. > The missing data is typical when not using flow control. When the OS > buffering fills, the hardware will start dropping bytes. I'm actually not getting MISSING data, I'm getting CORRUPTED data. If you look at my most recent post, I'm getting these bad bytes in place of the correct values: 0x2018, 0x2019, x2022, x2030, x201d. Why would is.read() return values not in the range of 0-255 ? Thanks. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 08:59:14 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 07:59:14 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: At 1:19 AM -0500 3/3/07, Keith wrote: >If I do a > >resultz = is.read(cbuf,0,15238); in java with RXTX > >where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > >and where resultz is an int, and cbuf is a char [] cbuf, resultz gets >EXACTLY 3968 bytes the first time called. If I call it multiple times, I get >roughly 11k total(less than what is sent), never more than the 3968 bytes >per is.read() call. > >My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 >bytes. Interesting numerical coincidence is that (max USB transfer) - (what you get) = 4096-3968 = 128 bytes is (almost) the size of the headers needed to transfer that much data. I think what you're seeing is the internal buffering of the USB data stream. You'll need some form of higher-level buffering to smooth that out. All hypotheses need to be tested. In this case, a test would be to check for missing data. If this idea is right, you'll get _all_ the data, but you won't be missing characters. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 09:26:14 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 11:26:14 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Bob, > Interesting numerical coincidence is that (max USB transfer) - (what > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > needed to transfer that much data. I was thinking along the same lines. I don't know USB well, but I do know that those numbers were close enough to warrant investigating the relationship between them. > I think what you're seeing is the internal buffering of the USB data > stream. You'll need some form of higher-level buffering to smooth > that out. Shouldn't the InputStreamReader() and BufferedReader() provide this type of buffering? Isn't that the idea behind those? > All hypotheses need to be tested. In this case, a test would be to > check for missing data. If this idea is right, you'll get _all_ the > data, but you won't be missing characters. I did start looking at the data. -- I'm getting weird results. I tried this: loopzz = 0; for (looptwo = 0; looptwo < 100000; looptwo++) { while (is.ready()) { cbuf[loopzz] = (char) is.read(); loopzz++; }} So I'm reading one character at a time. The good news is that loopzz is exactly 15238 at the end of the routine, which is perfectly correct. I picked looptwo value out of thin air. The weird results come in terms of the values, the data isn't correct at least in one case. Look here: 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). But the 0x89 was replaced by 0x2030. Why the heck would the returned value be 0x2030?? Why is the returned byte completely out of range? Why the multibyte return? >From InputStream in the API: read public abstract int read() throws IOExceptionReads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown. Value should be 0-255. In my application time is really critical, reading 1 byte at a time is probably not going to work. Thanks Eric & Bob for looking at this. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 14:44:50 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 13:44:50 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: Java's "char" type is Unicode. I think what you're seeing is a bug in the byte -> Unicode translation. 0x2018, 0x2019 are the curly open and close quotes. There used to be (and might still be) bugs in the conversion of these in a couple of libc versions. Some of the ASCII -> ISO and ISO -> ASCII routines were a little over-ambitious with respect to handling the open and close quotes, and tried to convert them to the "curly" form inappropriately. Try _not_ casting it to char. Bob At 11:26 AM -0500 3/3/07, Keith wrote: >Bob, > >> Interesting numerical coincidence is that (max USB transfer) - (what >> you get) = 4096-3968 = 128 bytes is (almost) the size of the headers >> needed to transfer that much data. > >I was thinking along the same lines. I don't know USB well, but I do know >that those numbers were close enough to warrant investigating the >relationship between them. > >> I think what you're seeing is the internal buffering of the USB data >> stream. You'll need some form of higher-level buffering to smooth >> that out. > >Shouldn't the InputStreamReader() and BufferedReader() provide this type of >buffering? Isn't that the idea behind those? > >> All hypotheses need to be tested. In this case, a test would be to >> check for missing data. If this idea is right, you'll get _all_ the >> data, but you won't be missing characters. > >I did start looking at the data. -- I'm getting weird results. > >I tried this: > >loopzz = 0; > >for (looptwo = 0; looptwo < 100000; looptwo++) { >while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > >}} > >So I'm reading one character at a time. The good news is that loopzz is >exactly 15238 at the end of the routine, which is perfectly correct. I >picked looptwo value out of thin air. > >The weird results come in terms of the values, the data isn't correct at >least in one case. Look here: > >0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > >This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). >But the 0x89 was replaced by 0x2030. Why the heck would the returned value >be 0x2030?? Why is the returned byte completely out of range? Why the >multibyte return? > >>From InputStream in the API: > >read >public abstract int read() > throws IOExceptionReads the next byte of data from the >input stream. The value byte is returned as an int in the range 0 to 255. If >no byte is available because the end of the stream has been reached, the >value -1 is returned. This method blocks until input data is available, the >end of the stream is detected, or an exception is thrown. >Value should be 0-255. > > >In my application time is really critical, reading 1 byte at a time is >probably not going to work. > >Thanks Eric & Bob for looking at this. > >Keith > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 15:10:11 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 17:10:11 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Bob said ..... > Java's "char" type is Unicode. I think what you're seeing is a bug > in the byte -> Unicode translation. Bob -- I think you hit the nail on the head. I was just coming to the same realization here. I knew that something funny was going on because the same bytes always got "corrupted." I'm pretty sure its in the InputStreamReader() functionality where the conversion junk is happening. Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. I don't know if simply changing the cast is going to work. Since the conversion is happening upstream (pun intended), I don't think my cast is doing this. Also I think the compiler forced me to use the cast. I'm still playing around, and I'll report back once I nail it down. Thanks!! Keith From tjarvi at qbang.org Sat Mar 3 15:59:46 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 15:59:46 -0700 (MST) Subject: [Rxtx] Win64 rxtx Testers? Message-ID: I have compiled win64 binaries of rxtx. Are there any users interested in testing them? If so, I'll look into putting them on the web site. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Mar 3 15:35:06 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 14:35:06 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: Because of this and similar problems, JMRI does all it's serial IO using +only+ byte values. It's a but of a pain, as Java wants to go to char and int types a little too aggressively, but it does solve the "uncontrolled conversions" problems. Bob At 5:10 PM -0500 3/3/07, Keith wrote: >Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > >Bob -- I think you hit the nail on the head. > >I was just coming to the same realization here. I knew that something funny >was going on because the same bytes always got "corrupted." > >I'm pretty sure its in the InputStreamReader() functionality where the >conversion junk is happening. > >Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > >I don't know if simply changing the cast is going to work. Since the >conversion is happening upstream (pun intended), I don't think my cast is >doing this. Also I think the compiler forced me to use the cast. -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mark at mdsh.com Sun Mar 4 11:01:33 2007 From: mark at mdsh.com (Mark Himsley) Date: Sun, 04 Mar 2007 18:01:33 +0000 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: <5C01AC72C200388815C04982@bedroom.mdsh.local> On 03 March 2007 14:38 -0500 Keith wrote: > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT > consistent. Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? It looks like you need to use DataInputStream and DataOutputStream. -- Mark Himsley From tjarvi at qbang.org Sun Mar 4 11:35:08 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 11:35:08 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" > > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > > * Line #21 - Not sure if you need a (TM) mark for > the term "Sun" > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > OK. I'm going through this today. Some groups ask if rxtx could be under their license also. I think this is a good example of why I resist multiple licenses and focus on why the current license may not be usable by them. The RXTX project is a convergence of hobby and commercial interests. I happen to do both right now. The problem with licensing is we have to stay on top of them as they change. Clearly, adding more licenses will not make this easier. I'm acting as the hobby person today. RXTX always favors the hobby people. But as we move forward, I'm going to need to bring this to lawyers at work and explain to them what is going on. Others here may have to do this also. I don't anticipate problems or unexpected changes. The goal is a consistant, comprehendable and usable license as close to what we have now as possible. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 14:52:10 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 14:52:10 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (1/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: I'm breaking this into two parts. I expect the second part will need more attention. Comments first, then the changed material below. On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > Thanks > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. OK. RXTX for consitent use. java should not be capitalized because it does not only mean Sun [TM] Java [TM]. An example of this not meaning Java is when people use RXTX with GCJ. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". There are not any contributors that are in all of RXTX yet but I did update the comment to try to reflect the current situation without making it a nightmare to maintain. I looked to see how the Linux kernel does it as a reference point. > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" The URL can be problematic. I have done so below with a time reference. GNU does not provide version information in their URLS. I picture this being a problem when the version 3 comes out. > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > This will be corrected when the copy is updated to the version linked below. ---------------- begin proposed material involved -------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. ----------------- end proposed material involved -------------------- I'll be looking at the linking issue again next. That should be all that remains other than including the 2.1 version. Let me know if you have problems with anything here. I do not want to dilute the material I post next with these housekeeping tasks. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 16:08:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 16:08:36 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: For those that are wondering what is going on here, this next bit is the meat of the changes. We agreed a long time ago to put this disclaimer in. We did a so so job. It was in rxtx 2.0, not well written, ... So some groups using rxtx that would like to ship rxtx so users don't need to download, install, go to the mail-list to find why it failed, ... Then their legal teams tell them section 5 paragraph 2 is a show stopper. That was never the intent. Now going through what remains... > and might need a (TM) suffix to make Sun happy. Added disclaimer at the ended 'all trademarks belong...' > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. OK. As you can see I was trying to adjust GNU text there for the LGPL. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. used dynamically linked terminology. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". I tried to address this more upfront with an intent statement. Let me know if you have problems with it. I also tried to make it a little more clear what was derived from the GNU solution by moving the link location closer to GNU's suggestion. > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > Thats the intent. Here is the combined fixes. Note that only the material in /*-- --*/ is being touched. The new GPL license is there but unmodified. ------------------------ begin proposed new license ------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. | | An executable that contains no derivative of any portion of RXTX, but | is designed to work with RXTX by being dynamically linked with it, | is considered a "work that uses the Library" subject to the terms and | conditions of the GNU Lesser General Public License. | | The following has been added to the RXTX License to remove | any confusion about linking to RXTX. We want to allow in part what | section 5, paragraph 2 of the LGPL does not permit in the special | case of linking over a controlled interface. The intent is to add a | Java Specification Request or standards body defined interface in the | future as another exception but one is not currently available. | | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface | | As a special exception, the copyright holders of RXTX give you | permission to link RXTX with independent modules that communicate with | RXTX solely through the Sun Microsytems CommAPI interface version 2, | regardless of the license terms of these independent modules, and to copy | and distribute the resulting combined work under terms of your choice, | provided that every copy of the combined work is accompanied by a complete | copy of the source code of RXTX (the version of RXTX used to produce the | combined work), being distributed under the terms of the GNU Lesser General | Public License plus this exception. An independent module is a | module which is not derived from or based on RXTX. | | Note that people who make modified versions of RXTX are not obligated | to grant this special exception for their modified versions; it is | their choice whether to do so. The GNU Lesser General Public License | gives permission to release a modified version without this exception; this | exception also makes it possible to release a modified version which | carries forward this exception. | | You should have received a copy of the GNU Lesser General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA | All trademarks belong to their respective owners. --------------------------------------------------------------------------*/ The original GNU Lesser General Public License Follows. GNU LESSER GENERAL PUBLIC LICENSE Version 2.1, February 1999 Copyright (C) 1991, 1999 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. [This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence the version number 2.1.] Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This license, the Lesser General Public License, applies to some specially designated software packages--typically libraries--of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below. When we speak of free software, we are referring to freedom of use, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish); that you receive source code or can get it if you want it; that you can change the software and use pieces of it in new free programs; and that you are informed that you can do these things. To protect your rights, we need to make restrictions that forbid distributors to deny you these rights or to ask you to surrender these rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library or if you modify it. For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights. We protect your rights with a two-step method: (1) we copyright the library, and (2) we offer you this license, which gives you legal permission to copy, distribute and/or modify the library. To protect each distributor, we want to make it very clear that there is no warranty for the free library. Also, if the library is modified by someone else and passed on, the recipients should know that what they have is not the original version, so that the original author's reputation will not be affected by problems that might be introduced by others. Finally, software patents pose a constant threat to the existence of any free program. We wish to make sure that a company cannot effectively restrict the users of a free program by obtaining a restrictive license from a patent holder. Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license. Most GNU software, including some libraries, is covered by the ordinary GNU General Public License. This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs. When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library. We call this license the "Lesser" General Public License because it does Less to protect the user's freedom than the ordinary General Public License. It also provides other free software developers Less of an advantage over competing non-free programs. These disadvantages are the reason we use the ordinary General Public License for many libraries. However, the Lesser license provides advantages in certain special circumstances. For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License. In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software. For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU operating system, as well as its variant, the GNU/Linux operating system. Although the Lesser General Public License is Less protective of the users' freedom, it does ensure that the user of a program that is linked with the Library has the freedom and the wherewithal to run that program using a modified version of the Library. The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, whereas the latter must be combined with the library in order to run. GNU LESSER GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License Agreement applies to any software library or other program which contains a notice placed by the copyright holder or other authorized party saying it may be distributed under the terms of this Lesser General Public License (also called "this License"). Each licensee is addressed as "you". A "library" means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables. The "Library", below, refers to any such software library or work which has been distributed under these terms. A "work based on the Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term "modification".) "Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library. Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does. 1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) The modified work must itself be a software library. b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change. c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License. d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful. (For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library. In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. 4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange. If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code. 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables. When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law. If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.) Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself. 6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications. You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things: a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.) b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. c) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution. d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place. e) Verify that the user has already received a copy of these materials or that you have already sent this user a copy. For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute. 7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things: a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above. b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work. 8. You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 9. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Library (or any work based on the Library), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Library or works based on it. 10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties with this License. 11. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply, and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 12. If the distribution and/or use of the Library is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Library under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 13. The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation. 14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Libraries If you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the ordinary General Public License). To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Also add information on how to contact you by electronic and paper mail. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the library, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the library `Frob' (a library for tweaking knobs) written by James Random Hacker. , 1 April 1990 Ty Coon, President of Vice That's all there is to it! ------------------------ end of proposed license ------------------ -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sun Mar 4 16:26:04 2007 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 04 Mar 2007 17:26:04 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <45EB558C.3010609@cox.net> Bob Jacobsen wrote: > Because of this and similar problems, JMRI does all it's serial IO > using +only+ byte values. It's a but of a pain, as Java wants to go > to char and int types a little too aggressively, but it does solve > the "uncontrolled conversions" problems. Anytime that you are reading bytes of data that is not printable, unicode text, in Java, you really need to stay away from the Readers. Use input stream only, or you will see unicode valued byte groups converted to unicode "char" values. Gregg Wonderly From joachim at buechse.de Mon Mar 5 04:23:48 2007 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 5 Mar 2007 12:23:48 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> The behaviour is exactly what you asked for in you code. is = new BufferedReader(new InputStreamReader(port.getInputStream())); Readers return Text (ie unicode chars) not bytes. You instantiate the InputStreamReader without saying which charset you want, which means "platform default". As this is on Windows, it will convert Windows characters to equivalent unicode characters. If you want to read bytes, read bytes not Text. Reading bytes is done with InputStream and BufferedInputStream. BTW: The InputStream and Reader methods that read arrays are not guarenteed to fill up the array. You always have to check what you really got, and advance your index accordingly. A typical "read up to 32k" method looks like this: InputStream is= ... // -- determine the max buffer size int len= is.available(); if (len == 0) { len= 32 * 1024; } // -- read all available data byte[] buffer= new byte[len]; int pos= 0; int read; do { read= is.read(buffer, pos, buffer.length - pos); pos= pos + read; } while (read != -1 && pos < buffer.length); Best regards, Joachim --- Joachim B?chse Phone: +41 44 500 2604 Buechse Consulting Hadlaubsteig 2 CH-8006 Z?rich On 03.03.2007, at 23:10, Keith wrote: > Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > > Bob -- I think you hit the nail on the head. > > I was just coming to the same realization here. I knew that > something funny > was going on because the same bytes always got "corrupted." > > I'm pretty sure its in the InputStreamReader() functionality where the > conversion junk is happening. > > Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > > I don't know if simply changing the cast is going to work. Since the > conversion is happening upstream (pun intended), I don't think my > cast is > doing this. Also I think the compiler forced me to use the cast. > > I'm still playing around, and I'll report back once I nail it down. > > Thanks!! > > Keith > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Mon Mar 5 07:25:46 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 05 Mar 2007 08:25:46 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> Message-ID: <45EC286A.8060608@cox.net> Joachim Buechse wrote: > BTW: The InputStream and Reader methods that read arrays are not > guarenteed to fill up the array. You always have to check what you > really got, and advance your index accordingly. A typical "read up to > 32k" method looks like this: > > InputStream is= ... > // -- determine the max buffer size > int len= is.available(); > if (len == 0) { > len= 32 * 1024; > } > // -- read all available data > byte[] buffer= new byte[len]; > int pos= 0; > int read; > do { > read= is.read(buffer, pos, buffer.length - pos); > pos= pos + read; > } while (read != -1 && pos < buffer.length); > My preferred structure is. byte arr[ len ]; int cnt; int off = 0; while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { off += cnt; } This keeps you from adding -1 to pos when the read returns -1. It also skips out when the read is 0 bytes which, is not a described EOF in InputStream java docs, but is a condition I want to be aware of. Gregg Wonderly From joachim at buechse.de Tue Mar 6 02:52:58 2007 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 6 Mar 2007 10:52:58 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <45EC286A.8060608@cox.net> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: The code I copied was from a file resource reader, it shouldn't really be applied to networking/external IO code. Mea culpa. However aborting when you get 0 from read is not always what you want either (you kind of indicated that already). Some unix java implementations will return 0 if the kernel read was aborted with EINTER, which is rarely the point where you want to abort your read - at least not without further checks. A "complete" solution always depends on the events you need to handle and the time the total read could take in reality. In some cases it's worth checking Thread.isInterrupted() in the loop, some code re-loops on 0 but only a limited number of times, some check a total timeout limit, etc... Best regards, Joachim On 05.03.2007, at 15:25, Gregg Wonderly wrote: > My preferred structure is. > > byte arr[ len ]; > int cnt; > int off = 0; > while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { > off += cnt; > } > > This keeps you from adding -1 to pos when the read returns -1. It > also skips > out when the read is 0 bytes which, is not a described EOF in > InputStream java > docs, but is a condition I want to be aware of. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Mar 6 14:47:44 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 Mar 2007 14:47:44 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: Just FYI, rxtx will usually not break out on EINTER. The code in the native library usually does something close to this: do { read(...) } while ( !done && errno==EINTR ); Obviously there is a little more involved but it will retry on EINTER if not done. On Tue, 6 Mar 2007, Joachim Buechse wrote: > The code I copied was from a file resource reader, it shouldn't > really be applied to networking/external IO code. Mea culpa. > > However aborting when you get 0 from read is not always what you want > either (you kind of indicated that already). Some unix java > implementations will return 0 if the kernel read was aborted with > EINTER, which is rarely the point where you want to abort your read - > at least not without further checks. A "complete" solution always > depends on the events you need to handle and the time the total read > could take in reality. In some cases it's worth checking > Thread.isInterrupted() in the loop, some code re-loops on 0 but only > a limited number of times, some check a total timeout limit, etc... > > Best regards, > Joachim > > On 05.03.2007, at 15:25, Gregg Wonderly wrote: >> My preferred structure is. >> >> byte arr[ len ]; >> int cnt; >> int off = 0; >> while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { >> off += cnt; >> } >> >> This keeps you from adding -1 to pos when the read returns -1. It >> also skips >> out when the read is 0 bytes which, is not a described EOF in >> InputStream java >> docs, but is a condition I want to be aware of. >> >> Gregg Wonderly >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 gjhanna at gmail.com Thu Mar 8 13:42:52 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Fri, 9 Mar 2007 09:42:52 +1300 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? Message-ID: I've just struck an issue using rxtx in a multi-threaded environment: If I have 3 threads trying to open *the same* comm-port I get a deadlock in CommPortIdentifier.open If I have just 2, it works fine - I get a PortInUseException which is nice and I can handle it. The 3 thread->deadlock thing is causing me issues. (Sample code below). This is from the java thread-dump Found one Java-level deadlock: ============================= "Thread-2": waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object ), which is held by "Thread-1" "Thread-1": waiting to lock monitor 0x0003e9cc (object 0x2450e108, a gnu.io.CommPortIdentifier), which is held by "Thread-2" Java stack information for the threads listed above: =================================================== "Thread-2": at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:329) - waiting to lock <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) "Thread-1": at java.lang.Object.wait(Native Method) - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) - locked <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) (Apart from this, rxtx is working fantastically for us). I'm thinking I'll have to implement some sort of locking mechanism that *doesn't* use java synchronization to prevent this situation. (Which doesn't sound like a good idea to me). Any ideas? Thanks, Greg Hanna ============= RXTXLockTest.java ======================================== import gnu.io.CommPort; import gnu.io.CommPortIdentifier; /** * @author Greg Hanna * Minimal code to create a deadlock with rxtx in multithreaded open */ public class RXTXLockTest { public static void main(String[] args) { try { CommPortIdentifier cpiCom1 = CommPortIdentifier.getPortIdentifier ("COM14"); OpenThread t1 = new OpenThread (" one ", cpiCom1); OpenThread t2 = new OpenThread (" two ", cpiCom1); OpenThread t3 = new OpenThread (" 003 ", cpiCom1); t1.start(); t2.start(); t3.start(); // comment this out and it runs with (expected) PortInUseException } catch (Exception e) { e.printStackTrace(); } } } class OpenThread extends Thread { String name; CommPortIdentifier cpi; CommPort cp; public OpenThread (String name, CommPortIdentifier cpi) { this.name = name; this.cpi = cpi; System.out.println (System.currentTimeMillis() + name + " thread created"); } public void run () { try { System.out.println (System.currentTimeMillis() + name + " opening"); cp = cpi.open(name, 2000); System.out.println (System.currentTimeMillis() + name + " opened - sleeping"); sleep (2000); // do the serial comms with the device. System.out.println (System.currentTimeMillis() + name + " slept - closing"); cp.close(); System.out.println (System.currentTimeMillis() + name + " closed - exiting"); } catch (Exception e) { System.out.println ("Error in thread: " + name ); e.printStackTrace(); } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070308/d9a163c5/attachment-0004.html From eu259473 at tele2.it Fri Mar 9 02:46:20 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 09 Mar 2007 10:46:20 +0100 Subject: [Rxtx] rxtx: tru64 unix make fails Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070309/3b654523/attachment-0004.html From lyon at docjava.com Fri Mar 9 03:58:32 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 Mar 2007 05:58:32 -0500 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi All, The deadlock issue is one that I have been thinking about for some time now. It seems to me that we need a resource manager that enables assignment to a known process. The one thing that seems important about serial ports is that two applications should not use the same serial port at the same time. When this happens, it throws an exception. OK. The exception is a response to a lock condition that arises from an unavailable resource. An abstract implementation (not born of native methods) might assign a serial port to an application, until the application releases it (or is forced to release it by some kill mechanism). Some resources (like a registry) can be reused. But others, like the serial port, cannot. In the case of the serial port, we would like, I think, to have the flyweight design pattern without sharing and with object assignment tracking. A means of breaking deadlock (like a leasing mechanism) seems very useful, to me. My guess is that we can serialize the state of the Parametric Singleton Pattern (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) into the Preferences of the System. Preferences.systemRoot() might help with that. When a resource is checked out, the lease time and owner are listed. A thread that does this can be killed, but applications outside of Java are problematic. There is a compelling problem here. It is not just serial ports. Sound cards, cameras, microphones, files, tape drives, etc. All are consumed resources that are assigned to an application (or user) and deprive other applications, or users, from use. What, if anything, should we do? At present we throw PortInUseExceptions. Is that it? Can we do better? OK, the port is in use. Now what? Do I have to be root to go remove lock files and kill applications? Is there a better way? Thanks! - Doug >I've just struck an issue using rxtx in a multi-threaded environment: > >If I have 3 threads trying to open *the same* >comm-port I get a deadlock in >CommPortIdentifier.open >If I have just 2, it works fine - I get a >PortInUseException which is nice and I can >handle it. > >The 3 thread->deadlock thing is causing me issues. >(Sample code below). > >This is from the java thread-dump > >Found one Java-level deadlock: >============================= >"Thread-2": > waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), > which is held by "Thread-1" >"Thread-1": > waiting to lock monitor 0x0003e9cc (object >0x2450e108, a gnu.io.CommPortIdentifier ), > which is held by "Thread-2" > >Java stack information for the threads listed above: >=================================================== >"Thread-2": > at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) > - waiting to lock <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) >"Thread-1": > at java.lang.Object.wait(Native Method) > - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) > - locked <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) > > >(Apart from this, rxtx is working fantastically for us). > >I'm thinking I'll have to implement some sort of >locking mechanism that *doesn't* use java >synchronization to prevent this situation. >(Which doesn't sound like a good idea to me). > >Any ideas? > >Thanks, > >Greg Hanna > >============= RXTXLockTest.java ======================================== > >import gnu.io.CommPort; >import gnu.io.CommPortIdentifier; > >/** > * @author Greg Hanna > * Minimal code to create a deadlock with rxtx in multithreaded open > */ >public class RXTXLockTest { > ? > ?public static void main(String[] args) { > ?try { > ?CommPortIdentifier cpiCom1 = >CommPortIdentifier.getPortIdentifier ("COM14"); > ?OpenThread t1 = new OpenThread (" one ", cpiCom1); > ?OpenThread t2 = new OpenThread (" two ", cpiCom1); > ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); > ?t1.start(); > ?t2.start(); > ?t3.start(); // comment this out >and it runs with (expected) PortInUseException > ?} catch (Exception e) { > ?e.printStackTrace(); > ?} > ?} >} > >class OpenThread extends Thread { > ?String name; > ?CommPortIdentifier cpi; > ?CommPort cp; > ?public OpenThread (String name, CommPortIdentifier cpi) { > ? this.name = name; > ?this.cpi = cpi; > ?System.out.println >(System.currentTimeMillis() + name + " thread >created"); > ?} > ?public void run () { > ?try { > ?System.out.println >(System.currentTimeMillis() + name + " opening"); > ?cp = cpi.open(name, 2000); > ?System.out.println >(System.currentTimeMillis() + name + " opened - >sleeping"); > ?sleep (2000); // do the serial comms with the device. > ?System.out.println >(System.currentTimeMillis() + name + " slept - >closing"); > ?cp.close(); > ?System.out.println >(System.currentTimeMillis() + name + " closed - >exiting"); > ?} catch (Exception e) { > System.out.println ("Error in thread: " + name ); > ?e.printStackTrace(); > ?} > ?} >} > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Mar 9 06:37:45 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 Mar 2007 06:37:45 -0700 (MST) Subject: [Rxtx] rxtx: tru64 unix make fails In-Reply-To: References: Message-ID: On Fri, 9 Mar 2007, "Giuseppe Marchese" wrote: > Sorry for delay. > ? > This is log for ./configure and make > error. > ? > thanks for attention > ? > Make: '%.java,$(TOP)/$(CLASSDEST)/%.class,$(wildcard $(SPATH)/*.java)': extra chars.? > Stop. > Hi Giuseppe You need to use GNU make with the Makefile. I suspect the tru64 make is not happy with those rules. > configure: exit 0 Looks like configure is fairly happy. From tjarvi at qbang.org Sat Mar 10 07:43:51 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 07:43:51 -0700 (MST) Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi Doug I have very little time to look into this further but what we could do is open up an rxtx 3 devel branch in which a proof of concept could be worked on. It could be the proof of concept for a JSR others including Sun could look at/work on or parts of it could be recycled in a JSR. I'm working very hard on rxtx right now but it does not show. I'm looking at win64, mac intel/ppc, usb bluetooth and usb serial dongles. Some are going to be more tested than others but they are all on the plate. I'll be pushing all the fixes upstream when they are done. So I'm very busy in 2.1 but we could open a new branch. On Fri, 9 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > The deadlock issue is one that I have been thinking about > for some time now. > It seems to me that we need a resource manager that enables assignment > to a known process. > > The one thing that seems important about serial > ports is that two applications should not use the > same serial port at the same time. When this > happens, it throws an exception. > OK. > > The exception is a response to a lock condition that > arises from an unavailable resource. > > An abstract implementation (not born of native methods) might > assign a serial port to an application, until the > application releases it (or is forced to release > it by some kill mechanism). > > Some resources (like a registry) can be reused. > But others, like the serial port, > cannot. > > In the case of the serial port, we would like, I think, to > have the flyweight design pattern > without sharing and with object assignment tracking. > A means of breaking deadlock (like a leasing > mechanism) seems very useful, to me. > > My guess is that we can serialize the state of the Parametric Singleton Pattern > (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) > into the Preferences of the System. Preferences.systemRoot() might help > with that. When a resource is checked out, the lease time and owner are > listed. A thread that does this can be killed, but applications outside of Java > are problematic. > > There is a compelling problem here. It is not just serial ports. > Sound cards, cameras, microphones, files, tape drives, etc. All are consumed > resources that are assigned to an application (or > user) and deprive other applications, > or users, from use. > > What, if anything, should we do? At present we throw PortInUseExceptions. > Is that it? > Can we do better? > OK, the port is in use. Now what? > Do I have to be root to go remove lock files and kill applications? > Is there a better way? > > Thanks! > - Doug > >> I've just struck an issue using rxtx in a multi-threaded environment: >> >> If I have 3 threads trying to open *the same* >> comm-port I get a deadlock in >> CommPortIdentifier.open >> If I have just 2, it works fine - I get a >> PortInUseException which is nice and I can >> handle it. >> >> The 3 thread->deadlock thing is causing me issues. >> (Sample code below). >> >> This is from the java thread-dump >> >> Found one Java-level deadlock: >> ============================= >> "Thread-2": >> waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), >> which is held by "Thread-1" >> "Thread-1": >> waiting to lock monitor 0x0003e9cc (object >> 0x2450e108, a gnu.io.CommPortIdentifier ), >> which is held by "Thread-2" >> >> Java stack information for the threads listed above: >> =================================================== >> "Thread-2": >> at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) >> - waiting to lock <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> "Thread-1": >> at java.lang.Object.wait(Native Method) >> - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) >> - locked <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> >> >> (Apart from this, rxtx is working fantastically for us). >> >> I'm thinking I'll have to implement some sort of >> locking mechanism that *doesn't* use java >> synchronization to prevent this situation. >> (Which doesn't sound like a good idea to me). >> >> Any ideas? >> >> Thanks, >> >> Greg Hanna >> >> ============= RXTXLockTest.java ======================================== >> >> import gnu.io.CommPort; >> import gnu.io.CommPortIdentifier; >> >> /** >> * @author Greg Hanna >> * Minimal code to create a deadlock with rxtx in multithreaded open >> */ >> public class RXTXLockTest { >> ? >> ?public static void main(String[] args) { >> ?try { >> ?CommPortIdentifier cpiCom1 = >> CommPortIdentifier.getPortIdentifier ("COM14"); >> ?OpenThread t1 = new OpenThread (" one ", cpiCom1); >> ?OpenThread t2 = new OpenThread (" two ", cpiCom1); >> ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); >> ?t1.start(); >> ?t2.start(); >> ?t3.start(); // comment this out >> and it runs with (expected) PortInUseException >> ?} catch (Exception e) { >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> class OpenThread extends Thread { >> ?String name; >> ?CommPortIdentifier cpi; >> ?CommPort cp; >> ?public OpenThread (String name, CommPortIdentifier cpi) { >> ? this.name = name; >> ?this.cpi = cpi; >> ?System.out.println >> (System.currentTimeMillis() + name + " thread >> created"); >> ?} >> ?public void run () { >> ?try { >> ?System.out.println >> (System.currentTimeMillis() + name + " opening"); >> ?cp = cpi.open(name, 2000); >> ?System.out.println >> (System.currentTimeMillis() + name + " opened - >> sleeping"); >> ?sleep (2000); // do the serial comms with the device. >> ?System.out.println >> (System.currentTimeMillis() + name + " slept - >> closing"); >> ?cp.close(); >> ?System.out.println >> (System.currentTimeMillis() + name + " closed - >> exiting"); >> ?} catch (Exception e) { >> System.out.println ("Error in thread: " + name ); >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 mm at UDel.Edu Sat Mar 10 14:48:32 2007 From: mm at UDel.Edu (Mike Markowski) Date: Sat, 10 Mar 2007 16:48:32 -0500 Subject: [Rxtx] rxtx and Sun's comm api Message-ID: <45F327B0.2060004@udel.edu> Hi all, I joined the list a few days ago and apologize for what is likely a frequently asked question, though I haven't yet found it anywhere. I learned about rxtx.org through the readme on Sun's version 2 of their comms api. They give recommendations in that readme regarding how a better comms api should be written. Is this the aim of rxtx.org? I wrote an app on my linux box using the Sun comms api (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the fact that only linux and Solaris are supported. So I'm glad to find rxtx.org and am just reading up on how make the conversion so Windows users will be able to run the program as well. At the same time I'm just curious if rxtx.org and Sun are both heading in the same direction. Thanks for any background or historical info. Feel free to point me to any www pages if my googling has just completely missed the target! Thanks again, Mike From tjarvi at qbang.org Sat Mar 10 15:35:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 15:35:25 -0700 (MST) Subject: [Rxtx] rxtx and Sun's comm api In-Reply-To: <45F327B0.2060004@udel.edu> References: <45F327B0.2060004@udel.edu> Message-ID: On Sat, 10 Mar 2007, Mike Markowski wrote: > Hi all, > > I joined the list a few days ago and apologize for what is likely a > frequently asked question, though I haven't yet found it anywhere. I > learned about rxtx.org through the readme on Sun's version 2 of their > comms api. They give recommendations in that readme regarding how a > better comms api should be written. Is this the aim of rxtx.org? > > I wrote an app on my linux box using the Sun comms api > (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the > fact that only linux and Solaris are supported. So I'm glad to find > rxtx.org and am just reading up on how make the conversion so Windows > users will be able to run the program as well. At the same time I'm > just curious if rxtx.org and Sun are both heading in the same direction. > > Thanks for any background or historical info. Feel free to point me to > any www pages if my googling has just completely missed the target! > I do not have any news (good or bad) concerning RXTX and Sun working together but perhaps others here do. The main goal of RXTX is to expose POSIX termios interfaces to java users. The future support of javax.comm is questionable. We do not have resources for everything. gnu.io (RXTX 2.1) will be supported going forward and functions the same as CommAPI 2.0. If you have control of the source code you are working with, I would not advise using CommAPI 2.0 javax.comm. We do support CommAPI 2.0 javax.comm for older applications but I do not think that will last much longer for practical reasons. The download interest in CommAPI 2.0 javax.comm support is becomming negligible on this end. There has been discussion of a JSR effort but I do not know of any status change since it was mentioned. One problem with a JSR is that even a light weight process is going to be difficult for RXTX at this time. Maybe that will change in the future but then again it may not. For now, we are just going forward 'as is' in rxtx 2.1 with package gnu.io while trying as a secondary effort to backport the changes to rxtx 2.0 for javax.comm support for users that do not have a choice. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Mar 11 07:19:40 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 11 Mar 2007 08:19:40 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: Hi All, I have been a proponent of a JSR that makes use of RXTX. I have executed the proper agreements with Sun. At this point we are in the: Early Draft Review of Draft Specifications Stage. The best thing to do is to enter the quiet period and create a specification. The question of exactly how we, as a group, want to approach this problem, remains open. Typically, we should have both a specification and a reference implementation. Thus, it would be to our best advantage to have a nice, stable, cross platform RXTX distro that adheres to the groups specification. Now, from a specification standpoint, my personal view on the matter is that we create a series of interfaces, with nice documentation (or at least javadoc). Is this a good idea? Should we have a pure interface specification for the communication API? There are several issues, in my mind, which still weigh on us. Hot-pluggable dongles, long discovery process on pop-up ports, lack of uniformity on device names, lack of uniformity on locking, a precise understanding of how the SerialPortResourceManager works (or even if we should have one). The more questions we answer in our reference implementation, the better our specification will get. RXTX is a good working prototype, but, I don't know if that is what we want to use for a specification. Here is what I have for a CommPortInterface: */ public interface CommPortInterface { /** * @return a string representation of this port. */ String toString(); /** * Gets the name of the communications port. This name should correspond to * something the user can identify, like the label on the hardware. * @return name of the port */ String getName(); /** * @return an input stream that can be used to read data from the * communications port. If the port doesn't support reading data, this * method returns null. *

* The blocking behaviour of this input stream depends on the threshold * and timeout values, as shown below for a read buffer size of n * bytes: * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ThresholdTimeoutBlocking behaviour
StateValueStateValue
disableddisabledblock until data is available
enabledm bytesdisabledblock until min(m, n) bytes are available
disabledenabledt msblock for t ms or until data is available
enabledm bytesenabledt msblock for t ms or until min(m, n) bytes are * available
* @throws java.io.IOException */ InputStream getInputStream() throws IOException; /** * @return an output stream that can be used to send data to the * communications port. If the port doesn't support sending data, this * method returns null. * @throws java.io.IOException */ OutputStream getOutputStream() throws IOException; /** * Closes this communications port. * All PortOwnershipListeners will be? * notified of this change of ownership. Further method calls on this? * object will throw IllegalStateException. Further calls on the? * associated InputStream or OutputStream will throw IOException. *

* Close does not block. Undelivered data is discarded. Blocked read and? * write operations are aborted if the underlying operating systems? * supports an IO abort mechanism. To await the delivery of undelivered? * data call OutputStream.flush() or OutputStream.close() before calling? * Port.close(). */ void close(); /** * Enables receive threshold. * When the specified threshold number of bytes are retrieved, read will * return immediately. * * @param thresh the number of bytes in the input buffer * @throws gnu.io.UnsupportedCommOperationException * if receive threshold is * not supported by the driver * @see #disableReceiveThreshold */ void enableReceiveThreshold(int thresh) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive threshold. * * @see #enableReceiveThreshold */ void disableReceiveThreshold(); /** * @return true if receive threshold is enabled. * * @see #enableReceiveThreshold */ boolean isReceiveThresholdEnabled(); /** * @return the receive threshold value. If receive threshold is diabled * or not supported, this value is meaningless. * * @see #enableReceiveThreshold */ int getReceiveThreshold(); /** * Enables receive timeout. * When the specified number of milliseconds have elapsed, read will * return immediately. * * @param rcvTimeout the number of milliseconds to block for * @throws gnu.io.UnsupportedCommOperationException * if receive timeout is * not supported by the driver * @see #disableReceiveTimeout */ void enableReceiveTimeout(int rcvTimeout) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive timeout. * * @see #enableReceiveTimeout */ void disableReceiveTimeout(); /** * @return true if receive timeout is enabled. * * @see #enableReceiveTimeout */ boolean isReceiveTimeoutEnabled(); /** * @return the receive timeout value. If receive timeout is diabled * or not supported, this value is meaningless. * * @see #enableReceiveTimeout */ int getReceiveTimeout(); /** * Enables receive framing. * The supplied byte value in the input suggests the end of the received * frame, and read returns immediately. Only the low 8 bits of the * supplied value are significant. * * @param framingByte the frame delimiter * @throws gnu.io.UnsupportedCommOperationException * if receive framing is * not supported by the driver * @see #disableReceiveFraming */ void enableReceiveFraming(int framingByte) throws UnsupportedCommOperationException; /** * Disables receive framing. * * @see #enableReceiveFraming */ void disableReceiveFraming(); /** * @return true if receive framing is enabled. * * @see #enableReceiveFraming */ boolean isReceiveFramingEnabled(); /** * @return true if receive framing byte. If receive framing is diabled * or not supported, this value is meaningless. * * @see #enableReceiveFraming */ int getReceiveFramingByte(); /** * Sets the input buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setInputBufferSize(int size); /** * @return the input buffer size. * The driver may choose not to report correct values. */ int getInputBufferSize(); /** * Sets the output buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setOutputBufferSize(int size); /** * @return the output buffer size. * The driver may choose not to report correct values. */ int getOutputBufferSize(); } What do you think of that? Note the wishy washy nature of the spec: The driver may choose to ignore this method. Is that good enough for us? Thanks! - Doug From ra85551 at gmail.com Sun Mar 11 08:44:45 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Sun, 11 Mar 2007 17:44:45 +0300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hello, world! I am writing application that communicates with modem via AT commands. My OS is Linux Kubuntu Feisty Herd, to ensure that my application will run properly under Windows XP I installed VMWare server. When I tried to send AT command and evaluate modem answer under WinXP @ VMWare server, I actually didn't receive anything. I think that VM settings are right, because I do can communicate with modem by using standard HyperTerminall as well as I can do on native Windows. So, why RXTX doesn't work under VM, but works under Linux and pure Windows XP (i tested it there) well? The send/receive method code follows. private String sendATCommand(String command, final String waitFor, final boolean isRegex, boolean isAddCRLF, long timeout) throws BeaconConnectException { final long POLL_PERIOD = 100; final int BUFFER_SIZE = 512; final byte[] buffer = new byte[BUFFER_SIZE]; final InputStream serialInput; final OutputStream serialOutput; try { serialInput = serialPort.getInputStream(); if (command != null) { serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } } catch (IOException e) { throw new MyException("serial I/O error"); } TimerTask task = new TimerTask() { int offset = 0; int bytesRead; public synchronized void run() { try { if (serialInput.available() > 0) { bytesRead = serialInput.read(buffer, offset, BUFFER_SIZE - offset); } else { return; } } catch (IOException e) { // do nothing - maybe next time we'll read something } offset += bytesRead; if (waitFor != null) { String temporary = new String(buffer, 0, offset).trim(); if (isRegex && temporary.matches(waitFor) || temporary.contains(waitFor)) { cancel(); notify(); } } } }; Timer timer = new Timer(); timer.schedule(task, POLL_PERIOD, POLL_PERIOD); synchronized (task) { try { task.wait(timeout); task.cancel(); } catch (InterruptedException e) { } } //Cut off leading and trailing CRs, LFs and zeroes String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); System.out.println(response); return response; } -- Pavel Parkhomenko From tjarvi at qbang.org Sun Mar 11 11:48:22 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:48:22 -0600 (MDT) Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: On Sun, 11 Mar 2007, Pavel Parkhomenko wrote: > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. > > private String sendATCommand(String command, final String waitFor, > final boolean isRegex, boolean isAddCRLF, long timeout) > throws BeaconConnectException > { > final long POLL_PERIOD = 100; > final int BUFFER_SIZE = 512; > final byte[] buffer = new byte[BUFFER_SIZE]; > final InputStream serialInput; > final OutputStream serialOutput; > try > { > serialInput = serialPort.getInputStream(); > if (command != null) > { > serialOutput = serialPort.getOutputStream(); > if (isAddCRLF) > { > command += "\r\n"; > } > System.out.println(command); > serialOutput.write(command.getBytes()); > } > } > catch (IOException e) > { > throw new MyException("serial I/O error"); > } > > TimerTask task = new TimerTask() > { > int offset = 0; > int bytesRead; > public synchronized void run() > { > try > { > if (serialInput.available() > 0) > { > bytesRead = serialInput.read(buffer, offset, > BUFFER_SIZE - offset); > } > else > { > return; > } > } > catch (IOException e) > { > // do nothing - maybe next time we'll read something > } > offset += bytesRead; > if (waitFor != null) > { > String temporary = new String(buffer, 0, offset).trim(); > if (isRegex && temporary.matches(waitFor) || > temporary.contains(waitFor)) > { > cancel(); > notify(); > } > } > } > }; > > Timer timer = new Timer(); > timer.schedule(task, POLL_PERIOD, POLL_PERIOD); > synchronized (task) { > try > { > task.wait(timeout); > task.cancel(); > } > catch (InterruptedException e) > { > } > } > //Cut off leading and trailing CRs, LFs and zeroes > String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); > System.out.println(response); > return response; > } > > > Hi Pavel VMWare should not be a problem. I've used it in the past - though not with a modem. Make sure nothing else is using the modem. Then look in the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an example that should work. Note that modems could care less what OS is on top. If you are trying to match new lines to the OS and sending it to the mode for AT commands, thats probably a mistake. Also it would not hurt to print out the individual bytes that you are sending to make sure they did not get mangled along the path. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 11:55:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:55:48 -0600 (MDT) Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: On Sun, 11 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > I have been a proponent of a JSR that makes > use of RXTX. I have executed the proper agreements with Sun. > > At this point we are in the: > Early Draft Review of Draft Specifications Stage. > > The best thing to do is to enter the quiet period and create > a specification. The question of exactly how we, as a group, > want to approach this problem, remains open. > > Typically, we should have both a specification and a reference > implementation. Thus, it would be to our best advantage to have > a nice, stable, cross platform RXTX distro that adheres to the > groups specification. > > Now, from a specification standpoint, my personal view on the matter is > that we create a series of interfaces, with nice documentation (or at least > javadoc). > > Is this a good idea? Should we have a pure interface specification for > the communication API? > > There are several issues, in my mind, which still weigh on us. > Hot-pluggable dongles, long discovery process on pop-up ports, > lack of uniformity on device names, lack of uniformity on locking, > a precise understanding of how the SerialPortResourceManager > works (or even if we should have one). > > The more questions we answer in our reference implementation, the > better our specification will get. RXTX is a good working prototype, > but, I don't know if that is what we want to use for a specification. > > Here is what I have for a CommPortInterface: > */ > public interface CommPortInterface { Hi Doug, I can start going through the method interfaces later this week and giving feedback. I would suggest that the JSR should not be too generic in nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel drivers that intend to look like EIA232 ports at the kernel driver level. some ideas: EIA232PortInterface TermiosInterface SerialPortInterface Something that differentiates this from thing like USB, I2C, ... which should not have to deal with legacy serial claiming to be the comm api. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 12:52:19 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 12:52:19 -0600 (MDT) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: No news is good news with these posts. I'll start the process of pinging legal a week from Monday on my end if nobody has objections to the proposal. I just want to make sure everyone has time to raise objections. Obviously, anyone can fork from a previous version if they don't like the new license. I suspect we can avoid that though. On Sun, 4 Mar 2007, Trent Jarvi wrote: > > For those that are wondering what is going on here, this > next bit is the meat of the changes. We agreed a long time > ago to put this disclaimer in. We did a so so job. It was > in rxtx 2.0, not well written, ... So some groups using > rxtx that would like to ship rxtx so users don't need to > download, install, go to the mail-list to find why it failed, > ... Then their legal teams tell them section 5 paragraph 2 > is a show stopper. > > That was never the intent. > > > Now going through what remains... > >> and might need a (TM) suffix to make Sun happy. > > Added disclaimer at the ended 'all trademarks belong...' > >> * Line #15ff - static vs. dynamic linking - you did >> not transcribe the text from the "controlled >> interface exception" when writing this text - and >> this was good so, because these terms originally >> refer to the GPL rather than the LGPL. I think though, >> that these 4 lines are the most important ones and >> should thus be really really clear. I hope that I >> meet your original intent with the following >> suggestions: >> 1.) Instead of "A program.." it would be better to >> say "An exectuable.." in order to be closer to >> the LGPL text. > > OK. As you can see I was trying to adjust GNU text there > for the LGPL. > >> 2.) It would be better to say .. "by being dynamically >> linked with it" to clearly indicate that dynamic >> linking is meant. The matter of compilation is >> already covered by the LGPL so mentioning it again >> just leads to confusion. > > used dynamically linked terminology. > >> 3.) It would be better to say .. "is considered a >> work that uses the library in contrast to section >> 5 of the LGPL, so the terms of the LGPL do not >> apply to the resulting executable". > > I tried to address this more upfront with an intent statement. > Let me know if you have problems with it. I also tried to > make it a little more clear what was derived from the GNU > solution by moving the link location closer to GNU's suggestion. > >> >> Note that LGPL section 5 says: ..."is called a >> "work that uses the Library". Such a work, in isolation, >> is not a derivative work of the Library, and therefore >> falls outside the scope of this License." >> The next paragraph of the LGPL is exactly the problematic >> one that I hope is clarified by the exception terms you >> give. >> > > Thats the intent. Here is the combined fixes. Note that only the > material in /*-- --*/ is being touched. The new GPL license is > there but unmodified. > > > ------------------------ begin proposed new license ------------------- > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Lesser General Public > | License as published by the Free Software Foundation; either > | version 2.1 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Lesser General Public License for more details. > | > | An executable that contains no derivative of any portion of RXTX, but > | is designed to work with RXTX by being dynamically linked with it, > | is considered a "work that uses the Library" subject to the terms and > | conditions of the GNU Lesser General Public License. > | > | The following has been added to the RXTX License to remove > | any confusion about linking to RXTX. We want to allow in part what > | section 5, paragraph 2 of the LGPL does not permit in the special > | case of linking over a controlled interface. The intent is to add a > | Java Specification Request or standards body defined interface in the > | future as another exception but one is not currently available. > | > | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface > | > | As a special exception, the copyright holders of RXTX give you > | permission to link RXTX with independent modules that communicate with > | RXTX solely through the Sun Microsytems CommAPI interface version 2, > | regardless of the license terms of these independent modules, and to copy > | and distribute the resulting combined work under terms of your choice, > | provided that every copy of the combined work is accompanied by a complete > | copy of the source code of RXTX (the version of RXTX used to produce the > | combined work), being distributed under the terms of the GNU Lesser General > | Public License plus this exception. An independent module is a > | module which is not derived from or based on RXTX. > | > | Note that people who make modified versions of RXTX are not obligated > | to grant this special exception for their modified versions; it is > | their choice whether to do so. The GNU Lesser General Public License > | gives permission to release a modified version without this exception; this > | exception also makes it possible to release a modified version which > | carries forward this exception. > | > | You should have received a copy of the GNU Lesser General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > | All trademarks belong to their respective owners. > --------------------------------------------------------------------------*/ > > The original GNU Lesser General Public License Follows. > > > GNU LESSER GENERAL PUBLIC LICENSE > Version 2.1, February 1999 > > Copyright (C) 1991, 1999 Free Software Foundation, Inc. > 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > Everyone is permitted to copy and distribute verbatim copies > of this license document, but changing it is not allowed. > > [This is the first released version of the Lesser GPL. It also counts > as the successor of the GNU Library Public License, version 2, hence > the version number 2.1.] > > Preamble > > The licenses for most software are designed to take away your > freedom to share and change it. By contrast, the GNU General Public > Licenses are intended to guarantee your freedom to share and change > free software--to make sure the software is free for all its users. > > This license, the Lesser General Public License, applies to some > specially designated software packages--typically libraries--of the > Free Software Foundation and other authors who decide to use it. You > can use it too, but we suggest you first think carefully about whether > this license or the ordinary General Public License is the better > strategy to use in any particular case, based on the explanations below. > > When we speak of free software, we are referring to freedom of use, > not price. Our General Public Licenses are designed to make sure that > you have the freedom to distribute copies of free software (and charge > for this service if you wish); that you receive source code or can get > it if you want it; that you can change the software and use pieces of > it in new free programs; and that you are informed that you can do > these things. > > To protect your rights, we need to make restrictions that forbid > distributors to deny you these rights or to ask you to surrender these > rights. These restrictions translate to certain responsibilities for > you if you distribute copies of the library or if you modify it. > > For example, if you distribute copies of the library, whether gratis > or for a fee, you must give the recipients all the rights that we gave > you. You must make sure that they, too, receive or can get the source > code. If you link other code with the library, you must provide > complete object files to the recipients, so that they can relink them > with the library after making changes to the library and recompiling > it. And you must show them these terms so they know their rights. > > We protect your rights with a two-step method: (1) we copyright the > library, and (2) we offer you this license, which gives you legal > permission to copy, distribute and/or modify the library. > > To protect each distributor, we want to make it very clear that > there is no warranty for the free library. Also, if the library is > modified by someone else and passed on, the recipients should know > that what they have is not the original version, so that the original > author's reputation will not be affected by problems that might be > introduced by others. > > Finally, software patents pose a constant threat to the existence of > any free program. We wish to make sure that a company cannot > effectively restrict the users of a free program by obtaining a > restrictive license from a patent holder. Therefore, we insist that > any patent license obtained for a version of the library must be > consistent with the full freedom of use specified in this license. > > Most GNU software, including some libraries, is covered by the > ordinary GNU General Public License. This license, the GNU Lesser > General Public License, applies to certain designated libraries, and > is quite different from the ordinary General Public License. We use > this license for certain libraries in order to permit linking those > libraries into non-free programs. > > When a program is linked with a library, whether statically or using > a shared library, the combination of the two is legally speaking a > combined work, a derivative of the original library. The ordinary > General Public License therefore permits such linking only if the > entire combination fits its criteria of freedom. The Lesser General > Public License permits more lax criteria for linking other code with > the library. > > We call this license the "Lesser" General Public License because it > does Less to protect the user's freedom than the ordinary General > Public License. It also provides other free software developers Less > of an advantage over competing non-free programs. These disadvantages > are the reason we use the ordinary General Public License for many > libraries. However, the Lesser license provides advantages in certain > special circumstances. > > For example, on rare occasions, there may be a special need to > encourage the widest possible use of a certain library, so that it becomes > a de-facto standard. To achieve this, non-free programs must be > allowed to use the library. A more frequent case is that a free > library does the same job as widely used non-free libraries. In this > case, there is little to gain by limiting the free library to free > software only, so we use the Lesser General Public License. > > In other cases, permission to use a particular library in non-free > programs enables a greater number of people to use a large body of > free software. For example, permission to use the GNU C Library in > non-free programs enables many more people to use the whole GNU > operating system, as well as its variant, the GNU/Linux operating > system. > > Although the Lesser General Public License is Less protective of the > users' freedom, it does ensure that the user of a program that is > linked with the Library has the freedom and the wherewithal to run > that program using a modified version of the Library. > > The precise terms and conditions for copying, distribution and > modification follow. Pay close attention to the difference between a > "work based on the library" and a "work that uses the library". The > former contains code derived from the library, whereas the latter must > be combined with the library in order to run. > > GNU LESSER GENERAL PUBLIC LICENSE > TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION > > 0. This License Agreement applies to any software library or other > program which contains a notice placed by the copyright holder or > other authorized party saying it may be distributed under the terms of > this Lesser General Public License (also called "this License"). > Each licensee is addressed as "you". > > A "library" means a collection of software functions and/or data > prepared so as to be conveniently linked with application programs > (which use some of those functions and data) to form executables. > > The "Library", below, refers to any such software library or work > which has been distributed under these terms. A "work based on the > Library" means either the Library or any derivative work under > copyright law: that is to say, a work containing the Library or a > portion of it, either verbatim or with modifications and/or translated > straightforwardly into another language. (Hereinafter, translation is > included without limitation in the term "modification".) > > "Source code" for a work means the preferred form of the work for > making modifications to it. For a library, complete source code means > all the source code for all modules it contains, plus any associated > interface definition files, plus the scripts used to control compilation > and installation of the library. > > Activities other than copying, distribution and modification are not > covered by this License; they are outside its scope. The act of > running a program using the Library is not restricted, and output from > such a program is covered only if its contents constitute a work based > on the Library (independent of the use of the Library in a tool for > writing it). Whether that is true depends on what the Library does > and what the program that uses the Library does. > > 1. You may copy and distribute verbatim copies of the Library's > complete source code as you receive it, in any medium, provided that > you conspicuously and appropriately publish on each copy an > appropriate copyright notice and disclaimer of warranty; keep intact > all the notices that refer to this License and to the absence of any > warranty; and distribute a copy of this License along with the > Library. > > You may charge a fee for the physical act of transferring a copy, > and you may at your option offer warranty protection in exchange for a > fee. > > 2. You may modify your copy or copies of the Library or any portion > of it, thus forming a work based on the Library, and copy and > distribute such modifications or work under the terms of Section 1 > above, provided that you also meet all of these conditions: > > a) The modified work must itself be a software library. > > b) You must cause the files modified to carry prominent notices > stating that you changed the files and the date of any change. > > c) You must cause the whole of the work to be licensed at no > charge to all third parties under the terms of this License. > > d) If a facility in the modified Library refers to a function or a > table of data to be supplied by an application program that uses > the facility, other than as an argument passed when the facility > is invoked, then you must make a good faith effort to ensure that, > in the event an application does not supply such function or > table, the facility still operates, and performs whatever part of > its purpose remains meaningful. > > (For example, a function in a library to compute square roots has > a purpose that is entirely well-defined independent of the > application. Therefore, Subsection 2d requires that any > application-supplied function or table used by this function must > be optional: if the application does not supply it, the square > root function must still compute square roots.) > > These requirements apply to the modified work as a whole. If > identifiable sections of that work are not derived from the Library, > and can be reasonably considered independent and separate works in > themselves, then this License, and its terms, do not apply to those > sections when you distribute them as separate works. But when you > distribute the same sections as part of a whole which is a work based > on the Library, the distribution of the whole must be on the terms of > this License, whose permissions for other licensees extend to the > entire whole, and thus to each and every part regardless of who wrote > it. > > Thus, it is not the intent of this section to claim rights or contest > your rights to work written entirely by you; rather, the intent is to > exercise the right to control the distribution of derivative or > collective works based on the Library. > > In addition, mere aggregation of another work not based on the Library > with the Library (or with a work based on the Library) on a volume of > a storage or distribution medium does not bring the other work under > the scope of this License. > > 3. You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. To do > this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version 2, > instead of to this License. (If a newer version than version 2 of the > ordinary GNU General Public License has appeared, then you can specify > that version instead if you wish.) Do not make any other change in > these notices. > > Once this change is made in a given copy, it is irreversible for > that copy, so the ordinary GNU General Public License applies to all > subsequent copies and derivative works made from that copy. > > This option is useful when you wish to copy part of the code of > the Library into a program that is not a library. > > 4. You may copy and distribute the Library (or a portion or > derivative of it, under Section 2) in object code or executable form > under the terms of Sections 1 and 2 above provided that you accompany > it with the complete corresponding machine-readable source code, which > must be distributed under the terms of Sections 1 and 2 above on a > medium customarily used for software interchange. > > If distribution of object code is made by offering access to copy > from a designated place, then offering equivalent access to copy the > source code from the same place satisfies the requirement to > distribute the source code, even though third parties are not > compelled to copy the source along with the object code. > > 5. A program that contains no derivative of any portion of the > Library, but is designed to work with the Library by being compiled or > linked with it, is called a "work that uses the Library". Such a > work, in isolation, is not a derivative work of the Library, and > therefore falls outside the scope of this License. > > However, linking a "work that uses the Library" with the Library > creates an executable that is a derivative of the Library (because it > contains portions of the Library), rather than a "work that uses the > library". The executable is therefore covered by this License. > Section 6 states terms for distribution of such executables. > > When a "work that uses the Library" uses material from a header file > that is part of the Library, the object code for the work may be a > derivative work of the Library even though the source code is not. > Whether this is true is especially significant if the work can be > linked without the Library, or if the work is itself a library. The > threshold for this to be true is not precisely defined by law. > > If such an object file uses only numerical parameters, data > structure layouts and accessors, and small macros and small inline > functions (ten lines or less in length), then the use of the object > file is unrestricted, regardless of whether it is legally a derivative > work. (Executables containing this object code plus portions of the > Library will still fall under Section 6.) > > Otherwise, if the work is a derivative of the Library, you may > distribute the object code for the work under the terms of Section 6. > Any executables containing that work also fall under Section 6, > whether or not they are linked directly with the Library itself. > > 6. As an exception to the Sections above, you may also combine or > link a "work that uses the Library" with the Library to produce a > work containing portions of the Library, and distribute that work > under terms of your choice, provided that the terms permit > modification of the work for the customer's own use and reverse > engineering for debugging such modifications. > > You must give prominent notice with each copy of the work that the > Library is used in it and that the Library and its use are covered by > this License. You must supply a copy of this License. If the work > during execution displays copyright notices, you must include the > copyright notice for the Library among them, as well as a reference > directing the user to the copy of this License. Also, you must do one > of these things: > > a) Accompany the work with the complete corresponding > machine-readable source code for the Library including whatever > changes were used in the work (which must be distributed under > Sections 1 and 2 above); and, if the work is an executable linked > with the Library, with the complete machine-readable "work that > uses the Library", as object code and/or source code, so that the > user can modify the Library and then relink to produce a modified > executable containing the modified Library. (It is understood > that the user who changes the contents of definitions files in the > Library will not necessarily be able to recompile the application > to use the modified definitions.) > > b) Use a suitable shared library mechanism for linking with the > Library. A suitable mechanism is one that (1) uses at run time a > copy of the library already present on the user's computer system, > rather than copying library functions into the executable, and (2) > will operate properly with a modified version of the library, if > the user installs one, as long as the modified version is > interface-compatible with the version that the work was made with. > > c) Accompany the work with a written offer, valid for at > least three years, to give the same user the materials > specified in Subsection 6a, above, for a charge no more > than the cost of performing this distribution. > > d) If distribution of the work is made by offering access to copy > from a designated place, offer equivalent access to copy the above > specified materials from the same place. > > e) Verify that the user has already received a copy of these > materials or that you have already sent this user a copy. > > For an executable, the required form of the "work that uses the > Library" must include any data and utility programs needed for > reproducing the executable from it. However, as a special exception, > the materials to be distributed need not include anything that is > normally distributed (in either source or binary form) with the major > components (compiler, kernel, and so on) of the operating system on > which the executable runs, unless that component itself accompanies > the executable. > > It may happen that this requirement contradicts the license > restrictions of other proprietary libraries that do not normally > accompany the operating system. Such a contradiction means you cannot > use both them and the Library together in an executable that you > distribute. > > 7. You may place library facilities that are a work based on the > Library side-by-side in a single library together with other library > facilities not covered by this License, and distribute such a combined > library, provided that the separate distribution of the work based on > the Library and of the other library facilities is otherwise > permitted, and provided that you do these two things: > > a) Accompany the combined library with a copy of the same work > based on the Library, uncombined with any other library > facilities. This must be distributed under the terms of the > Sections above. > > b) Give prominent notice with the combined library of the fact > that part of it is a work based on the Library, and explaining > where to find the accompanying uncombined form of the same work. > > 8. You may not copy, modify, sublicense, link with, or distribute > the Library except as expressly provided under this License. Any > attempt otherwise to copy, modify, sublicense, link with, or > distribute the Library is void, and will automatically terminate your > rights under this License. However, parties who have received copies, > or rights, from you under this License will not have their licenses > terminated so long as such parties remain in full compliance. > > 9. You are not required to accept this License, since you have not > signed it. However, nothing else grants you permission to modify or > distribute the Library or its derivative works. These actions are > prohibited by law if you do not accept this License. Therefore, by > modifying or distributing the Library (or any work based on the > Library), you indicate your acceptance of this License to do so, and > all its terms and conditions for copying, distributing or modifying > the Library or works based on it. > > 10. Each time you redistribute the Library (or any work based on the > Library), the recipient automatically receives a license from the > original licensor to copy, distribute, link with or modify the Library > subject to these terms and conditions. You may not impose any further > restrictions on the recipients' exercise of the rights granted herein. > You are not responsible for enforcing compliance by third parties with > this License. > > 11. If, as a consequence of a court judgment or allegation of patent > infringement or for any other reason (not limited to patent issues), > conditions are imposed on you (whether by court order, agreement or > otherwise) that contradict the conditions of this License, they do not > excuse you from the conditions of this License. If you cannot > distribute so as to satisfy simultaneously your obligations under this > License and any other pertinent obligations, then as a consequence you > may not distribute the Library at all. For example, if a patent > license would not permit royalty-free redistribution of the Library by > all those who receive copies directly or indirectly through you, then > the only way you could satisfy both it and this License would be to > refrain entirely from distribution of the Library. > > If any portion of this section is held invalid or unenforceable under any > particular circumstance, the balance of the section is intended to apply, > and the section as a whole is intended to apply in other circumstances. > > It is not the purpose of this section to induce you to infringe any > patents or other property right claims or to contest validity of any > such claims; this section has the sole purpose of protecting the > integrity of the free software distribution system which is > implemented by public license practices. Many people have made > generous contributions to the wide range of software distributed > through that system in reliance on consistent application of that > system; it is up to the author/donor to decide if he or she is willing > to distribute software through any other system and a licensee cannot > impose that choice. > > This section is intended to make thoroughly clear what is believed to > be a consequence of the rest of this License. > > 12. If the distribution and/or use of the Library is restricted in > certain countries either by patents or by copyrighted interfaces, the > original copyright holder who places the Library under this License may add > an explicit geographical distribution limitation excluding those countries, > so that distribution is permitted only in or among countries not thus > excluded. In such case, this License incorporates the limitation as if > written in the body of this License. > > 13. The Free Software Foundation may publish revised and/or new > versions of the Lesser General Public License from time to time. > Such new versions will be similar in spirit to the present version, > but may differ in detail to address new problems or concerns. > > Each version is given a distinguishing version number. If the Library > specifies a version number of this License which applies to it and > "any later version", you have the option of following the terms and > conditions either of that version or of any later version published by > the Free Software Foundation. If the Library does not specify a > license version number, you may choose any version ever published by > the Free Software Foundation. > > 14. If you wish to incorporate parts of the Library into other free > programs whose distribution conditions are incompatible with these, > write to the author to ask for permission. For software which is > copyrighted by the Free Software Foundation, write to the Free > Software Foundation; we sometimes make exceptions for this. Our > decision will be guided by the two goals of preserving the free status > of all derivatives of our free software and of promoting the sharing > and reuse of software generally. > > NO WARRANTY > > 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO > WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. > EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR > OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY > KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE > IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE > LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME > THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. > > 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN > WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY > AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU > FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR > CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE > LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING > RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A > FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF > SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH > DAMAGES. > > END OF TERMS AND CONDITIONS > > How to Apply These Terms to Your New Libraries > > If you develop a new library, and you want it to be of the greatest > possible use to the public, we recommend making it free software that > everyone can redistribute and change. You can do so by permitting > redistribution under these terms (or, alternatively, under the terms of the > ordinary General Public License). > > To apply these terms, attach the following notices to the library. It is > safest to attach them to the start of each source file to most effectively > convey the exclusion of warranty; and each file should have at least the > "copyright" line and a pointer to where the full notice is found. > > > Copyright (C) > > This library is free software; you can redistribute it and/or > modify it under the terms of the GNU Lesser General Public > License as published by the Free Software Foundation; either > version 2.1 of the License, or (at your option) any later version. > > This library is distributed in the hope that it will be useful, > but WITHOUT ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > Lesser General Public License for more details. > > You should have received a copy of the GNU Lesser General Public > License along with this library; if not, write to the Free Software > Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > > Also add information on how to contact you by electronic and paper mail. > > You should also get your employer (if you work as a programmer) or your > school, if any, to sign a "copyright disclaimer" for the library, if > necessary. Here is a sample; alter the names: > > Yoyodyne, Inc., hereby disclaims all copyright interest in the > library `Frob' (a library for tweaking knobs) written by James Random Hacker. > > , 1 April 1990 > Ty Coon, President of Vice > > That's all there is to it! > ------------------------ end of proposed license ------------------ > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From gjhanna at gmail.com Sun Mar 11 14:21:17 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Mon, 12 Mar 2007 09:21:17 +1300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hi Pavel, We are using RXTX under VMWare server in production, quite satisfactorily. We're using Red Hat Enterprise Server 4, and ... Whatever the "enterprise" VMWare product is. Regards, Greg H > Subject: [Rxtx] RXTX under VMWare server > To: rxtx at qbang.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. [ ... snip ... ] -- Pavel Parkhomenko -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070311/4cebb6f9/attachment-0004.html From gergg at cox.net Sun Mar 11 23:39:19 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 12 Mar 2007 00:39:19 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: <45F4E787.6050502@cox.net> Trent Jarvi wrote: > I can start going through the method interfaces later this week and giving > feedback. I would suggest that the JSR should not be too generic in > nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel > drivers that intend to look like EIA232 ports at the kernel driver level. > > some ideas: > > EIA232PortInterface > TermiosInterface > SerialPortInterface > > Something that differentiates this from thing like USB, I2C, ... which > should not have to deal with legacy serial claiming to be the comm api. I'm going to throw out a suggestion, which I am mostly serious about. What would happen if we took the appropriate bits of the J2ME connector API, and just used that as the new COMM API so that finally JSE and JME had a common foundation for these kinds of things? Gregg Wonderly From ra85551 at gmail.com Mon Mar 12 09:08:37 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Mon, 12 Mar 2007 18:08:37 +0300 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Should any application use the modem, HyperTerminal won't be able to talk to the modem. But it actually can send and receive AT comands, while my application cannot :-( > Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Thansk for the reference. I examined that example and found that there's no significant differences between my read/write implementation and that one, except that SimpleSnuV1 listens for serialEvent's, but not for sake of data retrieval, just for printing them out - I don't know why ;-) > Note that modems could care less what OS is on top. If you are trying to > match new lines to the OS and sending it to the mode for AT commands, > thats probably a mistake. I do send strings to serial port, not to OS, and do try to get answers back. If it is the mistake, what's the right way? > Also it would not hurt to print out the > individual bytes that you are sending to make sure they did not get > mangled along the path. Yeah, I am printing these bytes before doing write, but it means that I only see what I intend to write. How can I ensure that these bytes have gone out of the box and reached my modem? BTW, I found that my send/receive method is complex enough, so I've rewritten it. Please, see the following code and point any mistakes, because I don't know where can they remain yet. private static final int LARGE_TIMEOUT = 15000; private static final int SMALL_TIMEOUT = 500; ... private String sendATCommand(String command, String waitFor, boolean isRegex, boolean isAddCRLF) throws BeaconConnectException { byte[] buffer = new byte[512]; int offset; String result = ""; try { if (waitFor != null) { serialPort.enableReceiveTimeout(LARGE_TIMEOUT); } else { serialPort.enableReceiveTimeout(SMALL_TIMEOUT); } if (command != null) { OutputStream serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } offset = 0; InputStream serialInput = serialPort.getInputStream(); while (serialInput.available() != -1) { int bytesRead = serialInput.read(buffer, offset, buffer.length - offset); if (bytesRead == 0) { break; } offset += bytesRead; result = new String(buffer, 0, offset).trim(); if (waitFor != null) { System.out.println(result); if (isRegex && result.matches(waitFor) || result.contains(waitFor)) { break; } } } } catch (UnsupportedCommOperationException e) { throw new MyException("unsupported operation"); } catch (IOException e) { throw new MytException("serial I/O error"); } return result; } -- Pavel Parkhomenko From clayno at hotpop.com Thu Mar 15 02:47:34 2007 From: clayno at hotpop.com (Christopher Layno) Date: Thu, 15 Mar 2007 16:47:34 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi, we're using the latest release of rxtx (2.1-7r2) for our system that has two applications using the library. one application sends requests to the modem while the other simply checks the modem status. we deployed our system on a pentium machine with red hat linux 9.0 installed. now the problem arises when these two applications try to access the same modem at the same time. one of them will eventually have to throw the PortInUseException as shown below: 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException gnu.io.PortInUseException: root PID = 743 Program = java root PID = 743 Program = java root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) this was expected. what we didn't expect though was that if we repeat the scenario 5 times, always 5 times, the application would also throw a VM error: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4473CD21 Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so Current Java thread: at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) - locked <0x44cfd4c8> (a gnu.io.CommPortIdentifier) at ************ at ************ - locked <0x4476a468> (a **********) at ************ at ************ at ************ at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java :261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages( TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run( TCPTransport.java:701) at java.lang.Thread.run(Thread.java:534) note: i replaced some sensitive data with asterisks our team has looked everywhere on the internet, including your mail archives, for a solution to this problem but to no avail. i really hope you could help us out on this one. thanks in advance! best regards, chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070315/1936460a/attachment-0004.html From tjarvi at qbang.org Fri Mar 16 04:30:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 04:30:25 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: On Thu, 15 Mar 2007, Christopher Layno wrote: > hi, > > we're using the latest release of rxtx (2.1-7r2) for our system that has two > applications using the library. one application sends requests to the modem > while the other simply checks the modem status. we deployed our system on a > pentium machine with red hat linux 9.0 installed. > > now the problem arises when these two applications try to access the same > modem at the same time. one of them will eventually have to throw the > PortInUseException as shown below: > > 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException > gnu.io.PortInUseException: root PID = 743 Program = java root PID = > 743 Program = java root PID = 743 Program = ??? root PID = 743 Program > = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root > PID = 743 Program = ??? root PID = 743 Program = ??? > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > > this was expected. what we didn't expect though was that if we repeat the > scenario 5 times, always 5 times, the application would also throw a VM > error: > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x4473CD21 > Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 > Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so > > Current Java thread: > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) Hi Chris The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. The code is originally by Werner Almesberger. He gave us permission to use it in rxtx. You might look at what has changed since 1998 in his fuser application. Or you can just do like other OSs and do the following in fuserImp.c JNIEXPORT jstring JNICALL Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv *env, jobject obj, jstring arg) { return (*env)->NewStringUTF(env, "Unknown Application"); } It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. -- Trent Jarvi tjarvi at qang.org From Adrien.TOS at ingenico.com Fri Mar 16 05:11:12 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Fri, 16 Mar 2007 12:11:12 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903CBC312@frsnprexc1.usr.ingenico.loc> Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070316/972ab214/attachment-0004.html From joachim at buechse.de Fri Mar 16 05:13:24 2007 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 16 Mar 2007 12:13:24 +0100 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. From tjarvi at qbang.org Fri Mar 16 16:36:29 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 16:36:29 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Fri Mar 16 16:02:23 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 16 Mar 2007 18:02:23 -0400 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Not all platforms are Unix based. Also mixing native library usage and command-line calls is not an elegant solution, IMHO. One or the other, but not both. Andre On 16-Mar-07, at 07:13 , Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is > trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We >> only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From clayno at hotpop.com Sun Mar 18 22:17:28 2007 From: clayno at hotpop.com (Christopher Layno) Date: Mon, 19 Mar 2007 12:17:28 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi everyone, thank you so much for your replies. they were really helpful. anyway, before i sent the email, my team was already implementing a temporary solution by using joachim's suggestion. we invoked a lsof command from our java code although i share the same concern with trent and andre-john about portability issues. that's why i said it's just temporary. my superiors have yet to approve our bug fix. so my question now is this: is recompiling the rxtx source code the only way to solve this problem? because if it's the only solution, then i think my superiors would rather have a new release from the rxtx community itself that fixes this bug(?) rather than have my team recompile the source code. best regards, chris Trent Jarvi wrote: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. ... It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070318/237463b2/attachment-0004.html From tjarvi at qbang.org Mon Mar 19 16:20:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Mar 2007 16:20:52 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: Hi Chris I can compile a new version after the 21st if you do not feel comfortable doing so. Please send me an email reminder off-line then. On Mon, 19 Mar 2007, Christopher Layno wrote: > hi everyone, > > thank you so much for your replies. they were really helpful. > > anyway, before i sent the email, my team was already implementing a > temporary solution by using joachim's suggestion. > we invoked a lsof command from our java code although i share the same > concern with trent and andre-john about > portability issues. that's why i said it's just temporary. my superiors have > yet to approve our bug fix. > > so my question now is this: is recompiling the rxtx source code the only way > to solve this problem? because if it's the only > solution, then i think my superiors would rather have a new release from the > rxtx community itself that fixes this bug(?) > rather than have my team recompile the source code. > > best regards, > > chris > > Trent Jarvi wrote: > > Hi Joachim > > It would be nice to have that functionality but calling the program > introduces too many issues imho. Explaining to someone why rxtx invoked a > rogue lsof does not sound very interesting. > > On Fri, 16 Mar 2007, Joachim Buechse wrote: > > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: > > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. > > _______________________________________________ > Rxtx mailing list > Rxtx 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 Eric.Arseneau at sun.com Tue Mar 20 11:47:33 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Tue, 20 Mar 2007 10:47:33 -0700 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 Message-ID: <46001E35.9040608@sun.com> Anyone have any experience with RXTX working with JDK 6 on other platforms ? From mm at UDel.Edu Tue Mar 20 12:18:29 2007 From: mm at UDel.Edu (Mike Markowski) Date: Tue, 20 Mar 2007 14:18:29 -0400 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 In-Reply-To: <46001E35.9040608@sun.com> References: <46001E35.9040608@sun.com> Message-ID: <46002575.4000306@udel.edu> Eric Arseneau wrote: > Anyone have any experience with RXTX working with JDK 6 on other platforms ? I'm using 32 bit intel, gentoo linux, jdk6 with no problems. My applications only use a serial port, though, nothing on the parallel port. Mike From falko.guderian at gmx.de Wed Mar 21 08:17:35 2007 From: falko.guderian at gmx.de (Falko Guderian) Date: Wed, 21 Mar 2007 15:17:35 +0100 Subject: [Rxtx] RXTX binaries for SH4 Message-ID: <46013E7F.40102@gmx.de> Dear developers, I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no possiblities to compile the source code. Better, I'm not able to do this at the moment. Can you provide me with rxtxSerial.dll (SH4) in the rxtx-2.1-8-testing version? (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) The reason for the testing version is I need custom baud rates. Thanks for help. Kind regards, Falko Guderian From tjarvi at qbang.org Wed Mar 21 21:38:37 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Mar 2007 21:38:37 -0600 (MDT) Subject: [Rxtx] RXTX binaries for SH4 In-Reply-To: <46013E7F.40102@gmx.de> References: <46013E7F.40102@gmx.de> Message-ID: On Wed, 21 Mar 2007, Falko Guderian wrote: > Dear developers, > > I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no > possiblities to compile the source code. Better, I'm not able to do this > at the moment. Can you provide me with rxtxSerial.dll (SH4) in the > rxtx-2.1-8-testing version? > (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) > > The reason for the testing version is I need custom baud rates. > > Thanks for help. > Hi Falko WinCE binary format is not supported by gcc. That makes compiling limited to those familiar with the WinCE tools. I hope someone is able to provide them for you but it is not likely. WinCE has been compiled by others in the past but rxtx.org builds have never included WinCE. There is some information with the source concerning WinCE builds if you decide to do it. We can share your results too if you like. The source in the WinCE has never been updated for the custom baud rate. That would need changes from the main source I presume. If you look at the source, you will note that Michal Hobot created a mini fork in the source to handle wince but it has not been updated for 3 years. -- Trent Jarvi tjarvi at qbang.org From Adrien.TOS at ingenico.com Thu Mar 22 07:08:55 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Thu, 22 Mar 2007 14:08:55 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Hi everybody, Do you have any comments on this issue? Thanks! AT ________________________________ De : Adrien TOS Envoy? : vendredi 16 mars 2007 12:11 ? : 'rxtx at qbang.org' Cc : Adrien TOS Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070322/2306c538/attachment-0004.html From jeremy.reeve at zen.co.uk Mon Mar 19 07:36:04 2007 From: jeremy.reeve at zen.co.uk (Jeremy S. Reeve) Date: Mon, 19 Mar 2007 13:36:04 +0000 Subject: [Rxtx] rxtx failing to compile on Fedora Core 6 Message-ID: <1174311364.21865.6.camel@d9thc> When trying to compile latest source : rxtx-2.1-7r2 I get the following when running configure: ---------------- checking os.version 2.6.18-1.2200.fc5smp WARNING: configure is having a hard time determining which directory contains the file jni_md.h. Edit Makefile and fix the variable JAVANATINC to point to the correct directory. The following options are available: /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/ /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/linux/ If there are more than one option available the first was selected. WARNING: Kernel include files do not match the current kernel configure: creating ./config.status ------------------------ which seems OK checking the resultant Makefile but when attempting to build with gmake install I get the following output : ---------------------- 34 problems (34 warnings)/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/javah -classpath .:/home/jsr/rxtxsrc/rxtx-2.1-7r2:/home/jsr/rxtxsrc/rxtx-2.1-7r2/src:/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/ext/RXTXcomm.jar -d i686-pc-linux-gnu -jni `(for i in CommDriver CommPortEnumerator CommPortIdentifier CommPort CommPortOwnershipListener Configure I2C I2CPortEvent I2CPortEventListener I2CPort LPRPort NoSuchPortException ParallelPortEvent ParallelPortEventListener ParallelPort PortInUseException Raw RawPortEvent RawPortEventListener RawPort RS485 RS485PortEvent RS485PortEventListener RS485Port RXTXCommDriver RXTXPort RXTXVersion SerialPortEvent SerialPortEventListener SerialPort UnsupportedCommOperationException UnSupportedLoggerException Zystem;do \ if grep > /dev/null native.* \( /home/jsr/rxtxsrc/rxtx-2.1-7r2/./src/$i.java; then \ echo gnu.io.$i; \ fi; \ done)` i686-pc-linux-gnu/gnu_io_CommPortIdentifier.h: No such file or directory make: *** [/home/jsr/rxtxsrc/rxtx-2.1-7r2/gnu/io/CommDriver.class] Error 1 ------------------------ Any ideas or pointers? Regards, Jeremy From tjarvi at qbang.org Sat Mar 24 08:12:54 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 Mar 2007 08:12:54 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > From Adrien.TOS at ingenico.com Sat Mar 24 11:53:22 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Sat, 24 Mar 2007 18:53:22 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> I do not have the threshold setting enabled, I have explicitely disabled it with: port_.disableReceiveThreshold(); I have also run the same tests with the threshold setting enabled, but they also fail in the same way as described below. So it seems there is a problem with timeout handling on Win32? ________________________________ From: rxtx-bounces at qbang.org on behalf of Trent Jarvi Sent: Sat 3/24/2007 3:12 PM To: RXTX Developers and Users Subject: Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 8312 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20070324/f9e39c9b/attachment-0004.bin From greg.johnson at manchester.ac.uk Sun Mar 25 13:41:36 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Sun, 25 Mar 2007 21:41:36 +0200 Subject: [Rxtx] Mac intel weirdness Message-ID: Hi folks, I'm trying to get rxtx to work on my macbook pro with a USB-serial dongle on it. I am using the 2.1-8 code from the CVS (though it seems to report itself as 2.1-7: makes it difficult to prove to oneself that the changes have 'taken'! - line 4210 in SerialImp.c, line 40 in RXTXVersion.java) I am trying the 2.1-8 because of horrible lock problems in 2.1-7. However, the serialport closure code seems to be broken - it won't close because it believes the (previously opened!) port doesn't exist. Here is what I'm trying: 0. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "false" 1. Open a port Serialport serialport = (SerialPort) commportidentifier.open ("test",100); 2. Talk to a device ... 3. Close port serialport.close(); 4. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "true" - why is this? 5. Try to reopen port Serialport serialport2 = (SerialPort) commportidentifier.open("test", 100); throws PortInUseException. I've dug around a bit in the source, and it seems the SerialPort.close () should call the CommPortIdentifier.internalClosePort() (line 67 of CommPort.java). However, I crash out with the NoSuchPortException when getPortIdentifier is called. Which seems quite weird to me, seeing as it is called on this - which was create just beforehand. Does anyone know how to fix this? Cheers, greg From knute at frazmtn.com Sat Mar 24 10:32:38 2007 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 24 Mar 2007 09:32:38 -0700 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc>, Message-ID: <4604F036.17833.135298@knute.frazmtn.com> > >The behavior of timeout depends upon the setting of the threshold. Do you >have the threshold setting? > This is the same bug I reported last fall. There was a fellow that sent me an email asking if it had been fixed. I told him I didn't think so. He got somebody to write a fix for him but I have not been able to contact him again for the actual changes. The inaccurate timeout and the failure of blocking when no timeouts are set is a serious bug in my humble opinion and renders the software unusable for my applications. I'd really like to have an alternative to the Sun comm api but there just isn't one that I know of. -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Mar 26 16:17:00 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 26 Mar 2007 16:17:00 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> Message-ID: >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. From ra85551 at gmail.com Tue Mar 27 10:18:36 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Tue, 27 Mar 2007 20:18:36 +0400 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Ultimately I found a solution. At first, that wasn't actually the VMWare + WinXP + RXTX issue, that was WinXP + RXTX issue. But on pure XP it sometimes workes, sometimes not, while under VMWare I had never seen my snippet working at all. SimpleSnuV1.java would not help me, because there is only one line I missed, and SimpleSnuV1.java also doesn't contain it! It is as follows: serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_OUT | SerialPort.FLOWCONTROL_RTSCTS_IN); Thank you for your attention. -- Pavel Parkhomenko From griff at op.pl Wed Mar 28 01:28:19 2007 From: griff at op.pl (griff@op.pl) Date: Wed, 28 Mar 2007 09:28:19 +0200 Subject: [Rxtx] No blocking read on Windows. Message-ID: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/5d07d571/attachment-0004.html -------------- next part -------------- Hi, I have problem that InputStram.read() (SerialPort)?returns -1 instead blocking and waiting for data. I found that this problem was ?known in 2005 : ? >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > >> Hi Trent >> >> Thanks for the fast response. >> Here's a Q&D test program for the blocking read on windows that just >> attempts to read one byte, and prints the resulting byte. On my system it >> returns -1, where I expect that it keeps waiting for data. >> >This isn't happening on Linux so the bug is in src/termios.c.? I'll have >something this weekend to fix that. I'm using RXTX 2.1.7r2 and the problem still is here. Im using Windows XP and java 1.5 disableReciveTimeout() and disableReciveTreshhold() dont help. ? best regards ? Piotr Zielniok From Adrien.TOS at ingenico.com Wed Mar 28 01:40:46 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Wed, 28 Mar 2007 09:40:46 +0200 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903E88880@frsnprexc1.usr.ingenico.loc> Looking at the code, it seems there is no support for infinite timeout? And maybe the count++ < 20 condition is breaking out of the loop too early? The only condition to break out of the loop should either be the timeout has expired or the number of requested bytes has been received. -----Message d'origine----- De : rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] De la part de Trent Jarvi Envoy? : mardi 27 mars 2007 00:17 ? : RXTX Developers and Users Objet : Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From j.kenneth.gentle at acm.org Wed Mar 28 06:44:15 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 28 Mar 2007 08:44:15 -0400 Subject: [Rxtx] No blocking read on Windows. In-Reply-To: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> References: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> Message-ID: <200703281844.l2SIiITW028614@qbang.org> Just another "ME TOO!" - I'm seeing this problem on Windows XP, jre for windows XP/Embedded. I cranked receiveTimeout up to Integer.MAX_INT, but it doesn't seem to wait that long At 03:28 2007-03-28, you wrote: >Hi, >I have problem that InputStram.read() (SerialPort) returns -1 >instead blocking and waiting for data. I found that this problem >was known in 2005 : > > >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > > > >> Hi Trent > >> > >> Thanks for the fast response. > >> Here's a Q&D test program for the blocking read on windows that just > >> attempts to read one byte, and prints the resulting byte. On my system it > >> returns -1, where I expect that it keeps waiting for data. > >> > > >This isn't happening on Linux so the bug is in src/termios.c. I'll have > >something this weekend to fix that. > >I'm using RXTX 2.1.7r2 and the problem still is here. >Im using Windows XP and java 1.5 >disableReciveTimeout() and disableReciveTreshhold() dont help. > >best regards > >Piotr Zielniok > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From greg.johnson at manchester.ac.uk Wed Mar 28 14:43:29 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Wed, 28 Mar 2007 22:43:29 +0200 Subject: [Rxtx] Cannot close and reopen serial port Message-ID: <377F9765-7A9D-4CE9-9176-FFB63A2594F0@manchester.ac.uk> Dear all, It appears I cannot close a port properly: SerialPort serialport = portid.open("myprog",100); // do some stuff, all works fine serialport.close(); // all seems fine but... SerialPort sp2 = portid.open("myprog",100); throws PortInUseException. And when I dig into the rxtx code, I find in CommPort.java, in close(): CommPortIdentifier cp = CommPortIdentifier.getPortIdentifier(this); (line 64 or there abouts) but this throws a NoSuchPortException which is caught but ignored (line 74ish). Can anyone suggest how this could happen: a port that was valid, opened, and used, throws a NSPE when it comes to closing it? I'm pulling my (remaining) hair out over this one! Cheers, greg PS And thanks for RXTX - it's great to have! PPS (21.-7. winxp/osx both, java 1.5) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/c28852fc/attachment-0004.html From rxtx at vrijheidslaan.net Fri Mar 30 16:52:50 2007 From: rxtx at vrijheidslaan.net (Rob) Date: Fri, 30 Mar 2007 22:52:50 -0000 Subject: [Rxtx] Cvs Question Message-ID: <61896.80.126.150.87.1175295162.squirrel@webmail.provalue.nl> Hi There, Im trying to get the latest version to work on mac osx. Problem is that i can't checkout version 2.1.8. Probably my fault but can some one please give me the alternative commands for: [user at myhost]$ export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot [user at myhost]$ cvs login Thanx, Rob From ra85551 at gmail.com Thu Mar 1 03:47:06 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Thu, 1 Mar 2007 13:47:06 +0300 Subject: [Rxtx] enableReceiveTimeout() issue Message-ID: Hello, world! I found a limitation of 16300 ms for CommPort's enableReceiveTimeout() method, while in original javax.comm docs there are no any references to that. Is that a bug or feature? I actually need longer timeouts sometimees. -- Pavel Parkhomenko From lyon at docjava.com Thu Mar 1 07:54:17 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 01 Mar 2007 09:54:17 -0500 Subject: [Rxtx] parametric singleton design pattern In-Reply-To: References: <22d55aea0702081207q5e7f6785l352d498d6f5f9fb1@mail.gmail.com> <22d55aea0702100034o3bcf42f3j1d1a6257029a67b0@mail.gmail.com> Message-ID: Hi All, I have been thinking about the use of a design pattern to cache resources that are consumed by processes. Toward that end, I have arrived at a parametric singleton design pattern, which I mentioned on this list some time ago. The idea has been published at: http://www.jot.fm/issues/issue_2007_03/column2 I can't help but think that there should be an API available for dealing with the tracking of serial port usage. Perhaps it is a kind of resource manager called the: SerialPortManager basic prototypes already exist in this vain. See, for example: http://www.ce.rit.edu/research/projects/2005_fall/rt_poolsystem/doc/PoolMon/SerialPortManager.html http://www.eventhelix.com/RealtimeMantra/PatternCatalog/serial_port_design_pattern.htm And others shown by a google search on "SerialPortManager" Cheers! - Doug From Eric.Arseneau at sun.com Thu Mar 1 10:15:03 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:15:03 -0800 Subject: [Rxtx] Any known Java 6 issues with RXTX 2.1-7r2 ? Message-ID: <45E70A17.1060206@sun.com> I just did a test on a recent build of Solaris 11 x86 and it seems that I can connect to my serial device fine when Java 5 is the default, but when Java 6 is the default, no go. Any information ? From Eric.Arseneau at sun.com Thu Mar 1 10:19:58 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:19:58 -0800 Subject: [Rxtx] Mac OS X and missing data Message-ID: <45E70B3E.7040908@sun.com> We have a device which is USB based but presents itself as a serial port to a machine. On my MacBook Pro I can get excellent throughput if I get my device to send data as quickly as possible. On the desktop side, if I do an type of disk IO to log the data I get, I end up with some missing data at some point. I hooked up a USB analyzer and did confirm that all the data is sent as expected to the desktop from the device. I found a work around for this, buffer the data in memory and only write the data out when I've received it all. However, when the same code and same device is attempted on a co-workers MacBook Pro (same hardware specs), I get errors and must slow down dramatically the device side's sending of data. Any ideas/recommendations on what I can do to get rid of this error ? From what I can tell, it seems that RXTX is not able to wake up to the interrupts coming in indicating data is ready, quickly enough, is there anything I can do ? From chinkaiw at hotmail.com Fri Mar 2 00:57:43 2007 From: chinkaiw at hotmail.com (Wang Chinkai) Date: Fri, 02 Mar 2007 07:57:43 +0000 Subject: [Rxtx] dynamic detect rs232 port Message-ID: Hi all I have a question about detecting rs232 port dynamicly. I have to aceess some port and detect rs232 port at the same time. Some usb device simulates rs232 port , and I can not know what the port name it gets until it connects,so I have to detect it dynamic,but I have to access another rs232 device at the same time. I found a problem. If I use CommPortIdentifier.getPortIdentifiers() to get new port list , and the other rs232 access function will not close port correctly. So , How can I solve it . Thanks. _________________________________________________________________ ?? 2GB ???? Windows Live Mail ????????????? http://ideas.live.com/programpage.aspx?versionid=5d21c51a-b161-4314-9b0e-4911fb2b2e6d From eu259473 at tele2.it Fri Mar 2 06:16:40 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 02 Mar 2007 14:16:40 +0100 Subject: [Rxtx] rxtx on HP tru 64 unix Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070302/706c7a70/attachment-0005.html From tjarvi at qbang.org Fri Mar 2 08:39:33 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 08:39:33 -0700 (MST) Subject: [Rxtx] rxtx on HP tru 64 unix In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, "Giuseppe Marchese" wrote: > Hi > > I try to install rxtx on hp tru 64 but make fails, > There are somebody that do the same and work. > > > Sorry for may english! > > Hi Giuseppe Could you provide a log of the failure? script ./configure make # use gnu make exit The information will be in the typescript created. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 2 19:56:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 19:56:52 -0700 (MST) Subject: [Rxtx] dynamic detect rs232 port In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, Wang Chinkai wrote: > Hi all > > I have a question about detecting rs232 port dynamicly. > > I have to aceess some port and detect rs232 port at the same time. > Some usb device simulates rs232 port , and I can not know > what the port name it gets until it connects,so I have to detect it > dynamic,but I have to access > another rs232 device at the same time. > > I found a problem. Hi Wang This is a known problem. The code is braindead there. In fact there needs to be events even in a rudamentary way when you add a usb dongle. I'm burried in tasks not far from rxtx but not in rxtx. I can't get to the problem but we would accept patches if you dig into it. [I'm getting to the license question earlier too; I don't have another 10%] -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Fri Mar 2 23:19:01 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 01:19:01 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Hi, Under ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable USB -> serial converter(using virtual com port drivers), with using example code pretty much straight out of http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port opens fine, enumerations all work, etc. My application calls for a large amount of data to be transferred in a short amount of time at 2,000,000 baud. My hardware sends approximately 15,232 bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL converter work fine, and the application works using C++. In C++, I do a hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); to open the port, and a boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); to read the port. The variable buffer fills with the 15238 bytes, and returns. If I do a resultz = is.read(cbuf,0,15238); in java with RXTX where is = new BufferedReader(new InputStreamReader(port.getInputStream())); and where resultz is an int, and cbuf is a char [] cbuf, resultz gets EXACTLY 3968 bytes the first time called. If I call it multiple times, I get roughly 11k total(less than what is sent), never more than the 3968 bytes per is.read() call. My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 bytes. I've played with inputbuffersize, receive threshold, receivetimeout, and so on. The FTDI virtual com port drivers that I'm using are rock solid, and have had zero problems with them using a variety of applications, some of my own, some professionally written, etc. No flow control is used anyplace, no RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. No exceptions are being thrown. What am I doing wrong, and what I can adjust to receive the full 15k bytes in one single read? Thanks! Keith From Eric.Arseneau at sun.com Fri Mar 2 23:32:07 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Fri, 02 Mar 2007 22:32:07 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <45E91667.20501@sun.com> This is the same type of thing that is happening to me on Mac OS X and does not seem to behave the same on different machines. I posted a day or two ago on this with subject "Mac OS X and missing data". Would love to hear if there is a solution to this :) From tjarvi at qbang.org Sat Mar 3 10:54:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 10:54:17 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > Hi, > > Under > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable > USB -> serial converter(using virtual com port drivers), with using example > code pretty much straight out of > http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port > opens fine, enumerations all work, etc. > > My application calls for a large amount of data to be transferred in a short > amount of time at 2,000,000 baud. My hardware sends approximately 15,232 > bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL > converter work fine, and the application works using C++. > > In C++, I do a > > hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, > OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); > > to open the port, and a > > boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); > > to read the port. > > The variable buffer fills with the 15238 bytes, and returns. > > If I do a > > resultz = is.read(cbuf,0,15238); in java with RXTX > > where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > > and where resultz is an int, and cbuf is a char [] cbuf, resultz gets > EXACTLY 3968 bytes the first time called. If I call it multiple times, I get > roughly 11k total(less than what is sent), never more than the 3968 bytes > per is.read() call. > > My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 > bytes. > > I've played with inputbuffersize, receive threshold, receivetimeout, and so > on. The FTDI virtual com port drivers that I'm using are rock solid, and > have had zero problems with them using a variety of applications, some of my > own, some professionally written, etc. No flow control is used anyplace, no > RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. > > No exceptions are being thrown. > > What am I doing wrong, and what I can adjust to receive the full 15k bytes > in one single read? > > Thanks! > Hi Keith I would expect a 20 meg application is going to have different behavior with the OS than a smaller application with respect to the kernel memory managment, schedualing, ... Something subtle could be causing problems. With respect to the recieve timeout and threshold, if you set the timeout to zero and the threshold to the size of data you expect, read should not return until it get that data. You may try with a stand alone application that tests just that with the C/C++ API. If the read is returning with less data when tested for short reads, you have found a bug in the device driver more than likely. The USB dongle vendor would probably be interested in knowing about this. As mentioned, these devices are getting very good; almost bug free. I suspect you found a bug though if you did use the threshold and timeout properly. The missing data is typical when not using flow control. When the OS buffering fills, the hardware will start dropping bytes. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:38:52 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:38:52 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> update: I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now instead of 3968. This makes sense. 128 bytes of overhead + 3968 bytes of data = 4096 transfer size 32 bytes of overhead + 992 bytes of data = 1024 transfer size. 1/4 the data = 1/4 the overhead. I rearranged my reading like so: resultz = is.read(cbuf,0,3968); resultz = is.read(cbuf,3968,3968); resultz = is.read(cbuf,7936,3968); while (!(is.ready())); // wait for ready resultz = is.read(cbuf,11904,3334); and this grabs 15,238 bytes total. BUT, I still have the quandry of the screwed up multi-bytes. I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. Approx 8% of the data. The bad bytes always seem to take the flavor of 0x2018, 0x2019, x2022, x2030, x201d. Are these maybe errors and I don't know what they enumerate to? I still can't believe some other layer isn't handling putting those bytes together all in one stream for me. Thanks Keith ----- Original Message ----- From: "Keith" To: "Bob Jacobsen" ; "RXTX Developers and Users" Sent: Saturday, March 03, 2007 11:26 AM Subject: Re: [Rxtx] is.read() only returning 3968 bytes > Bob, > > > Interesting numerical coincidence is that (max USB transfer) - (what > > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > > needed to transfer that much data. > > I was thinking along the same lines. I don't know USB well, but I do know > that those numbers were close enough to warrant investigating the > relationship between them. > > > I think what you're seeing is the internal buffering of the USB data > > stream. You'll need some form of higher-level buffering to smooth > > that out. > > Shouldn't the InputStreamReader() and BufferedReader() provide this type of > buffering? Isn't that the idea behind those? > > > All hypotheses need to be tested. In this case, a test would be to > > check for missing data. If this idea is right, you'll get _all_ the > > data, but you won't be missing characters. > > I did start looking at the data. -- I'm getting weird results. > > I tried this: > > loopzz = 0; > > for (looptwo = 0; looptwo < 100000; looptwo++) { > while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > > }} > > So I'm reading one character at a time. The good news is that loopzz is > exactly 15238 at the end of the routine, which is perfectly correct. I > picked looptwo value out of thin air. > > The weird results come in terms of the values, the data isn't correct at > least in one case. Look here: > > 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > > This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). > But the 0x89 was replaced by 0x2030. Why the heck would the returned value > be 0x2030?? Why is the returned byte completely out of range? Why the > multibyte return? > > From InputStream in the API: > > read > public abstract int read() > throws IOExceptionReads the next byte of data from the > input stream. The value byte is returned as an int in the range 0 to 255. If > no byte is available because the end of the stream has been reached, the > value -1 is returned. This method blocks until input data is available, the > end of the stream is detected, or an exception is thrown. > Value should be 0-255. > > > In my application time is really critical, reading 1 byte at a time is > probably not going to work. > > Thanks Eric & Bob for looking at this. > > Keith > From tjarvi at qbang.org Sat Mar 3 12:52:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 12:52:27 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > update: > > I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now > instead of 3968. > > This makes sense. > > 128 bytes of overhead + 3968 bytes of data = 4096 transfer size > 32 bytes of overhead + 992 bytes of data = 1024 transfer size. > > 1/4 the data = 1/4 the overhead. > > I rearranged my reading like so: > > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. > Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? > > I still can't believe some other layer isn't handling putting those bytes > together all in one stream for me. > The layer for this in Serial land is flow control. Software and hardware flow control prevent the overruns you observe. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:54:41 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:54:41 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <001a01c75dcd$c8802a70$6600a8c0@jbh757ktruws7g> Trent, Thanks for taking the time to reply. > I would expect a 20 meg application is going to have different behavior > with the OS than a smaller application with respect to the kernel memory > managment, schedualing, ... Something subtle could be causing problems. Well, at least I know the VCP drivers, the OS, etc can handle 2mbps reliably. Without hiccuping or dropping bytes. The C++ code works reliably without flow control. > The missing data is typical when not using flow control. When the OS > buffering fills, the hardware will start dropping bytes. I'm actually not getting MISSING data, I'm getting CORRUPTED data. If you look at my most recent post, I'm getting these bad bytes in place of the correct values: 0x2018, 0x2019, x2022, x2030, x201d. Why would is.read() return values not in the range of 0-255 ? Thanks. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 08:59:14 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 07:59:14 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: At 1:19 AM -0500 3/3/07, Keith wrote: >If I do a > >resultz = is.read(cbuf,0,15238); in java with RXTX > >where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > >and where resultz is an int, and cbuf is a char [] cbuf, resultz gets >EXACTLY 3968 bytes the first time called. If I call it multiple times, I get >roughly 11k total(less than what is sent), never more than the 3968 bytes >per is.read() call. > >My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 >bytes. Interesting numerical coincidence is that (max USB transfer) - (what you get) = 4096-3968 = 128 bytes is (almost) the size of the headers needed to transfer that much data. I think what you're seeing is the internal buffering of the USB data stream. You'll need some form of higher-level buffering to smooth that out. All hypotheses need to be tested. In this case, a test would be to check for missing data. If this idea is right, you'll get _all_ the data, but you won't be missing characters. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 09:26:14 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 11:26:14 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Bob, > Interesting numerical coincidence is that (max USB transfer) - (what > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > needed to transfer that much data. I was thinking along the same lines. I don't know USB well, but I do know that those numbers were close enough to warrant investigating the relationship between them. > I think what you're seeing is the internal buffering of the USB data > stream. You'll need some form of higher-level buffering to smooth > that out. Shouldn't the InputStreamReader() and BufferedReader() provide this type of buffering? Isn't that the idea behind those? > All hypotheses need to be tested. In this case, a test would be to > check for missing data. If this idea is right, you'll get _all_ the > data, but you won't be missing characters. I did start looking at the data. -- I'm getting weird results. I tried this: loopzz = 0; for (looptwo = 0; looptwo < 100000; looptwo++) { while (is.ready()) { cbuf[loopzz] = (char) is.read(); loopzz++; }} So I'm reading one character at a time. The good news is that loopzz is exactly 15238 at the end of the routine, which is perfectly correct. I picked looptwo value out of thin air. The weird results come in terms of the values, the data isn't correct at least in one case. Look here: 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). But the 0x89 was replaced by 0x2030. Why the heck would the returned value be 0x2030?? Why is the returned byte completely out of range? Why the multibyte return? >From InputStream in the API: read public abstract int read() throws IOExceptionReads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown. Value should be 0-255. In my application time is really critical, reading 1 byte at a time is probably not going to work. Thanks Eric & Bob for looking at this. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 14:44:50 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 13:44:50 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: Java's "char" type is Unicode. I think what you're seeing is a bug in the byte -> Unicode translation. 0x2018, 0x2019 are the curly open and close quotes. There used to be (and might still be) bugs in the conversion of these in a couple of libc versions. Some of the ASCII -> ISO and ISO -> ASCII routines were a little over-ambitious with respect to handling the open and close quotes, and tried to convert them to the "curly" form inappropriately. Try _not_ casting it to char. Bob At 11:26 AM -0500 3/3/07, Keith wrote: >Bob, > >> Interesting numerical coincidence is that (max USB transfer) - (what >> you get) = 4096-3968 = 128 bytes is (almost) the size of the headers >> needed to transfer that much data. > >I was thinking along the same lines. I don't know USB well, but I do know >that those numbers were close enough to warrant investigating the >relationship between them. > >> I think what you're seeing is the internal buffering of the USB data >> stream. You'll need some form of higher-level buffering to smooth >> that out. > >Shouldn't the InputStreamReader() and BufferedReader() provide this type of >buffering? Isn't that the idea behind those? > >> All hypotheses need to be tested. In this case, a test would be to >> check for missing data. If this idea is right, you'll get _all_ the >> data, but you won't be missing characters. > >I did start looking at the data. -- I'm getting weird results. > >I tried this: > >loopzz = 0; > >for (looptwo = 0; looptwo < 100000; looptwo++) { >while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > >}} > >So I'm reading one character at a time. The good news is that loopzz is >exactly 15238 at the end of the routine, which is perfectly correct. I >picked looptwo value out of thin air. > >The weird results come in terms of the values, the data isn't correct at >least in one case. Look here: > >0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > >This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). >But the 0x89 was replaced by 0x2030. Why the heck would the returned value >be 0x2030?? Why is the returned byte completely out of range? Why the >multibyte return? > >>From InputStream in the API: > >read >public abstract int read() > throws IOExceptionReads the next byte of data from the >input stream. The value byte is returned as an int in the range 0 to 255. If >no byte is available because the end of the stream has been reached, the >value -1 is returned. This method blocks until input data is available, the >end of the stream is detected, or an exception is thrown. >Value should be 0-255. > > >In my application time is really critical, reading 1 byte at a time is >probably not going to work. > >Thanks Eric & Bob for looking at this. > >Keith > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 15:10:11 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 17:10:11 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Bob said ..... > Java's "char" type is Unicode. I think what you're seeing is a bug > in the byte -> Unicode translation. Bob -- I think you hit the nail on the head. I was just coming to the same realization here. I knew that something funny was going on because the same bytes always got "corrupted." I'm pretty sure its in the InputStreamReader() functionality where the conversion junk is happening. Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. I don't know if simply changing the cast is going to work. Since the conversion is happening upstream (pun intended), I don't think my cast is doing this. Also I think the compiler forced me to use the cast. I'm still playing around, and I'll report back once I nail it down. Thanks!! Keith From tjarvi at qbang.org Sat Mar 3 15:59:46 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 15:59:46 -0700 (MST) Subject: [Rxtx] Win64 rxtx Testers? Message-ID: I have compiled win64 binaries of rxtx. Are there any users interested in testing them? If so, I'll look into putting them on the web site. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Mar 3 15:35:06 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 14:35:06 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: Because of this and similar problems, JMRI does all it's serial IO using +only+ byte values. It's a but of a pain, as Java wants to go to char and int types a little too aggressively, but it does solve the "uncontrolled conversions" problems. Bob At 5:10 PM -0500 3/3/07, Keith wrote: >Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > >Bob -- I think you hit the nail on the head. > >I was just coming to the same realization here. I knew that something funny >was going on because the same bytes always got "corrupted." > >I'm pretty sure its in the InputStreamReader() functionality where the >conversion junk is happening. > >Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > >I don't know if simply changing the cast is going to work. Since the >conversion is happening upstream (pun intended), I don't think my cast is >doing this. Also I think the compiler forced me to use the cast. -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mark at mdsh.com Sun Mar 4 11:01:33 2007 From: mark at mdsh.com (Mark Himsley) Date: Sun, 04 Mar 2007 18:01:33 +0000 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: <5C01AC72C200388815C04982@bedroom.mdsh.local> On 03 March 2007 14:38 -0500 Keith wrote: > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT > consistent. Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? It looks like you need to use DataInputStream and DataOutputStream. -- Mark Himsley From tjarvi at qbang.org Sun Mar 4 11:35:08 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 11:35:08 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" > > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > > * Line #21 - Not sure if you need a (TM) mark for > the term "Sun" > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > OK. I'm going through this today. Some groups ask if rxtx could be under their license also. I think this is a good example of why I resist multiple licenses and focus on why the current license may not be usable by them. The RXTX project is a convergence of hobby and commercial interests. I happen to do both right now. The problem with licensing is we have to stay on top of them as they change. Clearly, adding more licenses will not make this easier. I'm acting as the hobby person today. RXTX always favors the hobby people. But as we move forward, I'm going to need to bring this to lawyers at work and explain to them what is going on. Others here may have to do this also. I don't anticipate problems or unexpected changes. The goal is a consistant, comprehendable and usable license as close to what we have now as possible. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 14:52:10 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 14:52:10 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (1/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: I'm breaking this into two parts. I expect the second part will need more attention. Comments first, then the changed material below. On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > Thanks > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. OK. RXTX for consitent use. java should not be capitalized because it does not only mean Sun [TM] Java [TM]. An example of this not meaning Java is when people use RXTX with GCJ. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". There are not any contributors that are in all of RXTX yet but I did update the comment to try to reflect the current situation without making it a nightmare to maintain. I looked to see how the Linux kernel does it as a reference point. > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" The URL can be problematic. I have done so below with a time reference. GNU does not provide version information in their URLS. I picture this being a problem when the version 3 comes out. > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > This will be corrected when the copy is updated to the version linked below. ---------------- begin proposed material involved -------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. ----------------- end proposed material involved -------------------- I'll be looking at the linking issue again next. That should be all that remains other than including the 2.1 version. Let me know if you have problems with anything here. I do not want to dilute the material I post next with these housekeeping tasks. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 16:08:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 16:08:36 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: For those that are wondering what is going on here, this next bit is the meat of the changes. We agreed a long time ago to put this disclaimer in. We did a so so job. It was in rxtx 2.0, not well written, ... So some groups using rxtx that would like to ship rxtx so users don't need to download, install, go to the mail-list to find why it failed, ... Then their legal teams tell them section 5 paragraph 2 is a show stopper. That was never the intent. Now going through what remains... > and might need a (TM) suffix to make Sun happy. Added disclaimer at the ended 'all trademarks belong...' > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. OK. As you can see I was trying to adjust GNU text there for the LGPL. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. used dynamically linked terminology. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". I tried to address this more upfront with an intent statement. Let me know if you have problems with it. I also tried to make it a little more clear what was derived from the GNU solution by moving the link location closer to GNU's suggestion. > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > Thats the intent. Here is the combined fixes. Note that only the material in /*-- --*/ is being touched. The new GPL license is there but unmodified. ------------------------ begin proposed new license ------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. | | An executable that contains no derivative of any portion of RXTX, but | is designed to work with RXTX by being dynamically linked with it, | is considered a "work that uses the Library" subject to the terms and | conditions of the GNU Lesser General Public License. | | The following has been added to the RXTX License to remove | any confusion about linking to RXTX. We want to allow in part what | section 5, paragraph 2 of the LGPL does not permit in the special | case of linking over a controlled interface. The intent is to add a | Java Specification Request or standards body defined interface in the | future as another exception but one is not currently available. | | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface | | As a special exception, the copyright holders of RXTX give you | permission to link RXTX with independent modules that communicate with | RXTX solely through the Sun Microsytems CommAPI interface version 2, | regardless of the license terms of these independent modules, and to copy | and distribute the resulting combined work under terms of your choice, | provided that every copy of the combined work is accompanied by a complete | copy of the source code of RXTX (the version of RXTX used to produce the | combined work), being distributed under the terms of the GNU Lesser General | Public License plus this exception. An independent module is a | module which is not derived from or based on RXTX. | | Note that people who make modified versions of RXTX are not obligated | to grant this special exception for their modified versions; it is | their choice whether to do so. The GNU Lesser General Public License | gives permission to release a modified version without this exception; this | exception also makes it possible to release a modified version which | carries forward this exception. | | You should have received a copy of the GNU Lesser General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA | All trademarks belong to their respective owners. --------------------------------------------------------------------------*/ The original GNU Lesser General Public License Follows. GNU LESSER GENERAL PUBLIC LICENSE Version 2.1, February 1999 Copyright (C) 1991, 1999 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. [This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence the version number 2.1.] Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This license, the Lesser General Public License, applies to some specially designated software packages--typically libraries--of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below. When we speak of free software, we are referring to freedom of use, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish); that you receive source code or can get it if you want it; that you can change the software and use pieces of it in new free programs; and that you are informed that you can do these things. To protect your rights, we need to make restrictions that forbid distributors to deny you these rights or to ask you to surrender these rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library or if you modify it. For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights. We protect your rights with a two-step method: (1) we copyright the library, and (2) we offer you this license, which gives you legal permission to copy, distribute and/or modify the library. To protect each distributor, we want to make it very clear that there is no warranty for the free library. Also, if the library is modified by someone else and passed on, the recipients should know that what they have is not the original version, so that the original author's reputation will not be affected by problems that might be introduced by others. Finally, software patents pose a constant threat to the existence of any free program. We wish to make sure that a company cannot effectively restrict the users of a free program by obtaining a restrictive license from a patent holder. Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license. Most GNU software, including some libraries, is covered by the ordinary GNU General Public License. This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs. When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library. We call this license the "Lesser" General Public License because it does Less to protect the user's freedom than the ordinary General Public License. It also provides other free software developers Less of an advantage over competing non-free programs. These disadvantages are the reason we use the ordinary General Public License for many libraries. However, the Lesser license provides advantages in certain special circumstances. For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License. In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software. For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU operating system, as well as its variant, the GNU/Linux operating system. Although the Lesser General Public License is Less protective of the users' freedom, it does ensure that the user of a program that is linked with the Library has the freedom and the wherewithal to run that program using a modified version of the Library. The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, whereas the latter must be combined with the library in order to run. GNU LESSER GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License Agreement applies to any software library or other program which contains a notice placed by the copyright holder or other authorized party saying it may be distributed under the terms of this Lesser General Public License (also called "this License"). Each licensee is addressed as "you". A "library" means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables. The "Library", below, refers to any such software library or work which has been distributed under these terms. A "work based on the Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term "modification".) "Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library. Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does. 1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) The modified work must itself be a software library. b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change. c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License. d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful. (For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library. In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. 4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange. If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code. 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables. When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law. If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.) Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself. 6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications. You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things: a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.) b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. c) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution. d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place. e) Verify that the user has already received a copy of these materials or that you have already sent this user a copy. For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute. 7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things: a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above. b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work. 8. You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 9. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Library (or any work based on the Library), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Library or works based on it. 10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties with this License. 11. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply, and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 12. If the distribution and/or use of the Library is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Library under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 13. The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation. 14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Libraries If you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the ordinary General Public License). To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Also add information on how to contact you by electronic and paper mail. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the library, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the library `Frob' (a library for tweaking knobs) written by James Random Hacker. , 1 April 1990 Ty Coon, President of Vice That's all there is to it! ------------------------ end of proposed license ------------------ -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sun Mar 4 16:26:04 2007 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 04 Mar 2007 17:26:04 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <45EB558C.3010609@cox.net> Bob Jacobsen wrote: > Because of this and similar problems, JMRI does all it's serial IO > using +only+ byte values. It's a but of a pain, as Java wants to go > to char and int types a little too aggressively, but it does solve > the "uncontrolled conversions" problems. Anytime that you are reading bytes of data that is not printable, unicode text, in Java, you really need to stay away from the Readers. Use input stream only, or you will see unicode valued byte groups converted to unicode "char" values. Gregg Wonderly From joachim at buechse.de Mon Mar 5 04:23:48 2007 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 5 Mar 2007 12:23:48 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> The behaviour is exactly what you asked for in you code. is = new BufferedReader(new InputStreamReader(port.getInputStream())); Readers return Text (ie unicode chars) not bytes. You instantiate the InputStreamReader without saying which charset you want, which means "platform default". As this is on Windows, it will convert Windows characters to equivalent unicode characters. If you want to read bytes, read bytes not Text. Reading bytes is done with InputStream and BufferedInputStream. BTW: The InputStream and Reader methods that read arrays are not guarenteed to fill up the array. You always have to check what you really got, and advance your index accordingly. A typical "read up to 32k" method looks like this: InputStream is= ... // -- determine the max buffer size int len= is.available(); if (len == 0) { len= 32 * 1024; } // -- read all available data byte[] buffer= new byte[len]; int pos= 0; int read; do { read= is.read(buffer, pos, buffer.length - pos); pos= pos + read; } while (read != -1 && pos < buffer.length); Best regards, Joachim --- Joachim B?chse Phone: +41 44 500 2604 Buechse Consulting Hadlaubsteig 2 CH-8006 Z?rich On 03.03.2007, at 23:10, Keith wrote: > Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > > Bob -- I think you hit the nail on the head. > > I was just coming to the same realization here. I knew that > something funny > was going on because the same bytes always got "corrupted." > > I'm pretty sure its in the InputStreamReader() functionality where the > conversion junk is happening. > > Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > > I don't know if simply changing the cast is going to work. Since the > conversion is happening upstream (pun intended), I don't think my > cast is > doing this. Also I think the compiler forced me to use the cast. > > I'm still playing around, and I'll report back once I nail it down. > > Thanks!! > > Keith > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Mon Mar 5 07:25:46 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 05 Mar 2007 08:25:46 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> Message-ID: <45EC286A.8060608@cox.net> Joachim Buechse wrote: > BTW: The InputStream and Reader methods that read arrays are not > guarenteed to fill up the array. You always have to check what you > really got, and advance your index accordingly. A typical "read up to > 32k" method looks like this: > > InputStream is= ... > // -- determine the max buffer size > int len= is.available(); > if (len == 0) { > len= 32 * 1024; > } > // -- read all available data > byte[] buffer= new byte[len]; > int pos= 0; > int read; > do { > read= is.read(buffer, pos, buffer.length - pos); > pos= pos + read; > } while (read != -1 && pos < buffer.length); > My preferred structure is. byte arr[ len ]; int cnt; int off = 0; while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { off += cnt; } This keeps you from adding -1 to pos when the read returns -1. It also skips out when the read is 0 bytes which, is not a described EOF in InputStream java docs, but is a condition I want to be aware of. Gregg Wonderly From joachim at buechse.de Tue Mar 6 02:52:58 2007 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 6 Mar 2007 10:52:58 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <45EC286A.8060608@cox.net> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: The code I copied was from a file resource reader, it shouldn't really be applied to networking/external IO code. Mea culpa. However aborting when you get 0 from read is not always what you want either (you kind of indicated that already). Some unix java implementations will return 0 if the kernel read was aborted with EINTER, which is rarely the point where you want to abort your read - at least not without further checks. A "complete" solution always depends on the events you need to handle and the time the total read could take in reality. In some cases it's worth checking Thread.isInterrupted() in the loop, some code re-loops on 0 but only a limited number of times, some check a total timeout limit, etc... Best regards, Joachim On 05.03.2007, at 15:25, Gregg Wonderly wrote: > My preferred structure is. > > byte arr[ len ]; > int cnt; > int off = 0; > while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { > off += cnt; > } > > This keeps you from adding -1 to pos when the read returns -1. It > also skips > out when the read is 0 bytes which, is not a described EOF in > InputStream java > docs, but is a condition I want to be aware of. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Mar 6 14:47:44 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 Mar 2007 14:47:44 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: Just FYI, rxtx will usually not break out on EINTER. The code in the native library usually does something close to this: do { read(...) } while ( !done && errno==EINTR ); Obviously there is a little more involved but it will retry on EINTER if not done. On Tue, 6 Mar 2007, Joachim Buechse wrote: > The code I copied was from a file resource reader, it shouldn't > really be applied to networking/external IO code. Mea culpa. > > However aborting when you get 0 from read is not always what you want > either (you kind of indicated that already). Some unix java > implementations will return 0 if the kernel read was aborted with > EINTER, which is rarely the point where you want to abort your read - > at least not without further checks. A "complete" solution always > depends on the events you need to handle and the time the total read > could take in reality. In some cases it's worth checking > Thread.isInterrupted() in the loop, some code re-loops on 0 but only > a limited number of times, some check a total timeout limit, etc... > > Best regards, > Joachim > > On 05.03.2007, at 15:25, Gregg Wonderly wrote: >> My preferred structure is. >> >> byte arr[ len ]; >> int cnt; >> int off = 0; >> while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { >> off += cnt; >> } >> >> This keeps you from adding -1 to pos when the read returns -1. It >> also skips >> out when the read is 0 bytes which, is not a described EOF in >> InputStream java >> docs, but is a condition I want to be aware of. >> >> Gregg Wonderly >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 gjhanna at gmail.com Thu Mar 8 13:42:52 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Fri, 9 Mar 2007 09:42:52 +1300 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? Message-ID: I've just struck an issue using rxtx in a multi-threaded environment: If I have 3 threads trying to open *the same* comm-port I get a deadlock in CommPortIdentifier.open If I have just 2, it works fine - I get a PortInUseException which is nice and I can handle it. The 3 thread->deadlock thing is causing me issues. (Sample code below). This is from the java thread-dump Found one Java-level deadlock: ============================= "Thread-2": waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object ), which is held by "Thread-1" "Thread-1": waiting to lock monitor 0x0003e9cc (object 0x2450e108, a gnu.io.CommPortIdentifier), which is held by "Thread-2" Java stack information for the threads listed above: =================================================== "Thread-2": at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:329) - waiting to lock <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) "Thread-1": at java.lang.Object.wait(Native Method) - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) - locked <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) (Apart from this, rxtx is working fantastically for us). I'm thinking I'll have to implement some sort of locking mechanism that *doesn't* use java synchronization to prevent this situation. (Which doesn't sound like a good idea to me). Any ideas? Thanks, Greg Hanna ============= RXTXLockTest.java ======================================== import gnu.io.CommPort; import gnu.io.CommPortIdentifier; /** * @author Greg Hanna * Minimal code to create a deadlock with rxtx in multithreaded open */ public class RXTXLockTest { public static void main(String[] args) { try { CommPortIdentifier cpiCom1 = CommPortIdentifier.getPortIdentifier ("COM14"); OpenThread t1 = new OpenThread (" one ", cpiCom1); OpenThread t2 = new OpenThread (" two ", cpiCom1); OpenThread t3 = new OpenThread (" 003 ", cpiCom1); t1.start(); t2.start(); t3.start(); // comment this out and it runs with (expected) PortInUseException } catch (Exception e) { e.printStackTrace(); } } } class OpenThread extends Thread { String name; CommPortIdentifier cpi; CommPort cp; public OpenThread (String name, CommPortIdentifier cpi) { this.name = name; this.cpi = cpi; System.out.println (System.currentTimeMillis() + name + " thread created"); } public void run () { try { System.out.println (System.currentTimeMillis() + name + " opening"); cp = cpi.open(name, 2000); System.out.println (System.currentTimeMillis() + name + " opened - sleeping"); sleep (2000); // do the serial comms with the device. System.out.println (System.currentTimeMillis() + name + " slept - closing"); cp.close(); System.out.println (System.currentTimeMillis() + name + " closed - exiting"); } catch (Exception e) { System.out.println ("Error in thread: " + name ); e.printStackTrace(); } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070308/d9a163c5/attachment-0005.html From eu259473 at tele2.it Fri Mar 9 02:46:20 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 09 Mar 2007 10:46:20 +0100 Subject: [Rxtx] rxtx: tru64 unix make fails Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070309/3b654523/attachment-0005.html From lyon at docjava.com Fri Mar 9 03:58:32 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 Mar 2007 05:58:32 -0500 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi All, The deadlock issue is one that I have been thinking about for some time now. It seems to me that we need a resource manager that enables assignment to a known process. The one thing that seems important about serial ports is that two applications should not use the same serial port at the same time. When this happens, it throws an exception. OK. The exception is a response to a lock condition that arises from an unavailable resource. An abstract implementation (not born of native methods) might assign a serial port to an application, until the application releases it (or is forced to release it by some kill mechanism). Some resources (like a registry) can be reused. But others, like the serial port, cannot. In the case of the serial port, we would like, I think, to have the flyweight design pattern without sharing and with object assignment tracking. A means of breaking deadlock (like a leasing mechanism) seems very useful, to me. My guess is that we can serialize the state of the Parametric Singleton Pattern (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) into the Preferences of the System. Preferences.systemRoot() might help with that. When a resource is checked out, the lease time and owner are listed. A thread that does this can be killed, but applications outside of Java are problematic. There is a compelling problem here. It is not just serial ports. Sound cards, cameras, microphones, files, tape drives, etc. All are consumed resources that are assigned to an application (or user) and deprive other applications, or users, from use. What, if anything, should we do? At present we throw PortInUseExceptions. Is that it? Can we do better? OK, the port is in use. Now what? Do I have to be root to go remove lock files and kill applications? Is there a better way? Thanks! - Doug >I've just struck an issue using rxtx in a multi-threaded environment: > >If I have 3 threads trying to open *the same* >comm-port I get a deadlock in >CommPortIdentifier.open >If I have just 2, it works fine - I get a >PortInUseException which is nice and I can >handle it. > >The 3 thread->deadlock thing is causing me issues. >(Sample code below). > >This is from the java thread-dump > >Found one Java-level deadlock: >============================= >"Thread-2": > waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), > which is held by "Thread-1" >"Thread-1": > waiting to lock monitor 0x0003e9cc (object >0x2450e108, a gnu.io.CommPortIdentifier ), > which is held by "Thread-2" > >Java stack information for the threads listed above: >=================================================== >"Thread-2": > at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) > - waiting to lock <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) >"Thread-1": > at java.lang.Object.wait(Native Method) > - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) > - locked <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) > > >(Apart from this, rxtx is working fantastically for us). > >I'm thinking I'll have to implement some sort of >locking mechanism that *doesn't* use java >synchronization to prevent this situation. >(Which doesn't sound like a good idea to me). > >Any ideas? > >Thanks, > >Greg Hanna > >============= RXTXLockTest.java ======================================== > >import gnu.io.CommPort; >import gnu.io.CommPortIdentifier; > >/** > * @author Greg Hanna > * Minimal code to create a deadlock with rxtx in multithreaded open > */ >public class RXTXLockTest { > ? > ?public static void main(String[] args) { > ?try { > ?CommPortIdentifier cpiCom1 = >CommPortIdentifier.getPortIdentifier ("COM14"); > ?OpenThread t1 = new OpenThread (" one ", cpiCom1); > ?OpenThread t2 = new OpenThread (" two ", cpiCom1); > ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); > ?t1.start(); > ?t2.start(); > ?t3.start(); // comment this out >and it runs with (expected) PortInUseException > ?} catch (Exception e) { > ?e.printStackTrace(); > ?} > ?} >} > >class OpenThread extends Thread { > ?String name; > ?CommPortIdentifier cpi; > ?CommPort cp; > ?public OpenThread (String name, CommPortIdentifier cpi) { > ? this.name = name; > ?this.cpi = cpi; > ?System.out.println >(System.currentTimeMillis() + name + " thread >created"); > ?} > ?public void run () { > ?try { > ?System.out.println >(System.currentTimeMillis() + name + " opening"); > ?cp = cpi.open(name, 2000); > ?System.out.println >(System.currentTimeMillis() + name + " opened - >sleeping"); > ?sleep (2000); // do the serial comms with the device. > ?System.out.println >(System.currentTimeMillis() + name + " slept - >closing"); > ?cp.close(); > ?System.out.println >(System.currentTimeMillis() + name + " closed - >exiting"); > ?} catch (Exception e) { > System.out.println ("Error in thread: " + name ); > ?e.printStackTrace(); > ?} > ?} >} > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Mar 9 06:37:45 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 Mar 2007 06:37:45 -0700 (MST) Subject: [Rxtx] rxtx: tru64 unix make fails In-Reply-To: References: Message-ID: On Fri, 9 Mar 2007, "Giuseppe Marchese" wrote: > Sorry for delay. > ? > This is log for ./configure and make > error. > ? > thanks for attention > ? > Make: '%.java,$(TOP)/$(CLASSDEST)/%.class,$(wildcard $(SPATH)/*.java)': extra chars.? > Stop. > Hi Giuseppe You need to use GNU make with the Makefile. I suspect the tru64 make is not happy with those rules. > configure: exit 0 Looks like configure is fairly happy. From tjarvi at qbang.org Sat Mar 10 07:43:51 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 07:43:51 -0700 (MST) Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi Doug I have very little time to look into this further but what we could do is open up an rxtx 3 devel branch in which a proof of concept could be worked on. It could be the proof of concept for a JSR others including Sun could look at/work on or parts of it could be recycled in a JSR. I'm working very hard on rxtx right now but it does not show. I'm looking at win64, mac intel/ppc, usb bluetooth and usb serial dongles. Some are going to be more tested than others but they are all on the plate. I'll be pushing all the fixes upstream when they are done. So I'm very busy in 2.1 but we could open a new branch. On Fri, 9 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > The deadlock issue is one that I have been thinking about > for some time now. > It seems to me that we need a resource manager that enables assignment > to a known process. > > The one thing that seems important about serial > ports is that two applications should not use the > same serial port at the same time. When this > happens, it throws an exception. > OK. > > The exception is a response to a lock condition that > arises from an unavailable resource. > > An abstract implementation (not born of native methods) might > assign a serial port to an application, until the > application releases it (or is forced to release > it by some kill mechanism). > > Some resources (like a registry) can be reused. > But others, like the serial port, > cannot. > > In the case of the serial port, we would like, I think, to > have the flyweight design pattern > without sharing and with object assignment tracking. > A means of breaking deadlock (like a leasing > mechanism) seems very useful, to me. > > My guess is that we can serialize the state of the Parametric Singleton Pattern > (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) > into the Preferences of the System. Preferences.systemRoot() might help > with that. When a resource is checked out, the lease time and owner are > listed. A thread that does this can be killed, but applications outside of Java > are problematic. > > There is a compelling problem here. It is not just serial ports. > Sound cards, cameras, microphones, files, tape drives, etc. All are consumed > resources that are assigned to an application (or > user) and deprive other applications, > or users, from use. > > What, if anything, should we do? At present we throw PortInUseExceptions. > Is that it? > Can we do better? > OK, the port is in use. Now what? > Do I have to be root to go remove lock files and kill applications? > Is there a better way? > > Thanks! > - Doug > >> I've just struck an issue using rxtx in a multi-threaded environment: >> >> If I have 3 threads trying to open *the same* >> comm-port I get a deadlock in >> CommPortIdentifier.open >> If I have just 2, it works fine - I get a >> PortInUseException which is nice and I can >> handle it. >> >> The 3 thread->deadlock thing is causing me issues. >> (Sample code below). >> >> This is from the java thread-dump >> >> Found one Java-level deadlock: >> ============================= >> "Thread-2": >> waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), >> which is held by "Thread-1" >> "Thread-1": >> waiting to lock monitor 0x0003e9cc (object >> 0x2450e108, a gnu.io.CommPortIdentifier ), >> which is held by "Thread-2" >> >> Java stack information for the threads listed above: >> =================================================== >> "Thread-2": >> at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) >> - waiting to lock <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> "Thread-1": >> at java.lang.Object.wait(Native Method) >> - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) >> - locked <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> >> >> (Apart from this, rxtx is working fantastically for us). >> >> I'm thinking I'll have to implement some sort of >> locking mechanism that *doesn't* use java >> synchronization to prevent this situation. >> (Which doesn't sound like a good idea to me). >> >> Any ideas? >> >> Thanks, >> >> Greg Hanna >> >> ============= RXTXLockTest.java ======================================== >> >> import gnu.io.CommPort; >> import gnu.io.CommPortIdentifier; >> >> /** >> * @author Greg Hanna >> * Minimal code to create a deadlock with rxtx in multithreaded open >> */ >> public class RXTXLockTest { >> ? >> ?public static void main(String[] args) { >> ?try { >> ?CommPortIdentifier cpiCom1 = >> CommPortIdentifier.getPortIdentifier ("COM14"); >> ?OpenThread t1 = new OpenThread (" one ", cpiCom1); >> ?OpenThread t2 = new OpenThread (" two ", cpiCom1); >> ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); >> ?t1.start(); >> ?t2.start(); >> ?t3.start(); // comment this out >> and it runs with (expected) PortInUseException >> ?} catch (Exception e) { >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> class OpenThread extends Thread { >> ?String name; >> ?CommPortIdentifier cpi; >> ?CommPort cp; >> ?public OpenThread (String name, CommPortIdentifier cpi) { >> ? this.name = name; >> ?this.cpi = cpi; >> ?System.out.println >> (System.currentTimeMillis() + name + " thread >> created"); >> ?} >> ?public void run () { >> ?try { >> ?System.out.println >> (System.currentTimeMillis() + name + " opening"); >> ?cp = cpi.open(name, 2000); >> ?System.out.println >> (System.currentTimeMillis() + name + " opened - >> sleeping"); >> ?sleep (2000); // do the serial comms with the device. >> ?System.out.println >> (System.currentTimeMillis() + name + " slept - >> closing"); >> ?cp.close(); >> ?System.out.println >> (System.currentTimeMillis() + name + " closed - >> exiting"); >> ?} catch (Exception e) { >> System.out.println ("Error in thread: " + name ); >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 mm at UDel.Edu Sat Mar 10 14:48:32 2007 From: mm at UDel.Edu (Mike Markowski) Date: Sat, 10 Mar 2007 16:48:32 -0500 Subject: [Rxtx] rxtx and Sun's comm api Message-ID: <45F327B0.2060004@udel.edu> Hi all, I joined the list a few days ago and apologize for what is likely a frequently asked question, though I haven't yet found it anywhere. I learned about rxtx.org through the readme on Sun's version 2 of their comms api. They give recommendations in that readme regarding how a better comms api should be written. Is this the aim of rxtx.org? I wrote an app on my linux box using the Sun comms api (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the fact that only linux and Solaris are supported. So I'm glad to find rxtx.org and am just reading up on how make the conversion so Windows users will be able to run the program as well. At the same time I'm just curious if rxtx.org and Sun are both heading in the same direction. Thanks for any background or historical info. Feel free to point me to any www pages if my googling has just completely missed the target! Thanks again, Mike From tjarvi at qbang.org Sat Mar 10 15:35:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 15:35:25 -0700 (MST) Subject: [Rxtx] rxtx and Sun's comm api In-Reply-To: <45F327B0.2060004@udel.edu> References: <45F327B0.2060004@udel.edu> Message-ID: On Sat, 10 Mar 2007, Mike Markowski wrote: > Hi all, > > I joined the list a few days ago and apologize for what is likely a > frequently asked question, though I haven't yet found it anywhere. I > learned about rxtx.org through the readme on Sun's version 2 of their > comms api. They give recommendations in that readme regarding how a > better comms api should be written. Is this the aim of rxtx.org? > > I wrote an app on my linux box using the Sun comms api > (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the > fact that only linux and Solaris are supported. So I'm glad to find > rxtx.org and am just reading up on how make the conversion so Windows > users will be able to run the program as well. At the same time I'm > just curious if rxtx.org and Sun are both heading in the same direction. > > Thanks for any background or historical info. Feel free to point me to > any www pages if my googling has just completely missed the target! > I do not have any news (good or bad) concerning RXTX and Sun working together but perhaps others here do. The main goal of RXTX is to expose POSIX termios interfaces to java users. The future support of javax.comm is questionable. We do not have resources for everything. gnu.io (RXTX 2.1) will be supported going forward and functions the same as CommAPI 2.0. If you have control of the source code you are working with, I would not advise using CommAPI 2.0 javax.comm. We do support CommAPI 2.0 javax.comm for older applications but I do not think that will last much longer for practical reasons. The download interest in CommAPI 2.0 javax.comm support is becomming negligible on this end. There has been discussion of a JSR effort but I do not know of any status change since it was mentioned. One problem with a JSR is that even a light weight process is going to be difficult for RXTX at this time. Maybe that will change in the future but then again it may not. For now, we are just going forward 'as is' in rxtx 2.1 with package gnu.io while trying as a secondary effort to backport the changes to rxtx 2.0 for javax.comm support for users that do not have a choice. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Mar 11 07:19:40 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 11 Mar 2007 08:19:40 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: Hi All, I have been a proponent of a JSR that makes use of RXTX. I have executed the proper agreements with Sun. At this point we are in the: Early Draft Review of Draft Specifications Stage. The best thing to do is to enter the quiet period and create a specification. The question of exactly how we, as a group, want to approach this problem, remains open. Typically, we should have both a specification and a reference implementation. Thus, it would be to our best advantage to have a nice, stable, cross platform RXTX distro that adheres to the groups specification. Now, from a specification standpoint, my personal view on the matter is that we create a series of interfaces, with nice documentation (or at least javadoc). Is this a good idea? Should we have a pure interface specification for the communication API? There are several issues, in my mind, which still weigh on us. Hot-pluggable dongles, long discovery process on pop-up ports, lack of uniformity on device names, lack of uniformity on locking, a precise understanding of how the SerialPortResourceManager works (or even if we should have one). The more questions we answer in our reference implementation, the better our specification will get. RXTX is a good working prototype, but, I don't know if that is what we want to use for a specification. Here is what I have for a CommPortInterface: */ public interface CommPortInterface { /** * @return a string representation of this port. */ String toString(); /** * Gets the name of the communications port. This name should correspond to * something the user can identify, like the label on the hardware. * @return name of the port */ String getName(); /** * @return an input stream that can be used to read data from the * communications port. If the port doesn't support reading data, this * method returns null. *

* The blocking behaviour of this input stream depends on the threshold * and timeout values, as shown below for a read buffer size of n * bytes: * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ThresholdTimeoutBlocking behaviour
StateValueStateValue
disableddisabledblock until data is available
enabledm bytesdisabledblock until min(m, n) bytes are available
disabledenabledt msblock for t ms or until data is available
enabledm bytesenabledt msblock for t ms or until min(m, n) bytes are * available
* @throws java.io.IOException */ InputStream getInputStream() throws IOException; /** * @return an output stream that can be used to send data to the * communications port. If the port doesn't support sending data, this * method returns null. * @throws java.io.IOException */ OutputStream getOutputStream() throws IOException; /** * Closes this communications port. * All PortOwnershipListeners will be? * notified of this change of ownership. Further method calls on this? * object will throw IllegalStateException. Further calls on the? * associated InputStream or OutputStream will throw IOException. *

* Close does not block. Undelivered data is discarded. Blocked read and? * write operations are aborted if the underlying operating systems? * supports an IO abort mechanism. To await the delivery of undelivered? * data call OutputStream.flush() or OutputStream.close() before calling? * Port.close(). */ void close(); /** * Enables receive threshold. * When the specified threshold number of bytes are retrieved, read will * return immediately. * * @param thresh the number of bytes in the input buffer * @throws gnu.io.UnsupportedCommOperationException * if receive threshold is * not supported by the driver * @see #disableReceiveThreshold */ void enableReceiveThreshold(int thresh) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive threshold. * * @see #enableReceiveThreshold */ void disableReceiveThreshold(); /** * @return true if receive threshold is enabled. * * @see #enableReceiveThreshold */ boolean isReceiveThresholdEnabled(); /** * @return the receive threshold value. If receive threshold is diabled * or not supported, this value is meaningless. * * @see #enableReceiveThreshold */ int getReceiveThreshold(); /** * Enables receive timeout. * When the specified number of milliseconds have elapsed, read will * return immediately. * * @param rcvTimeout the number of milliseconds to block for * @throws gnu.io.UnsupportedCommOperationException * if receive timeout is * not supported by the driver * @see #disableReceiveTimeout */ void enableReceiveTimeout(int rcvTimeout) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive timeout. * * @see #enableReceiveTimeout */ void disableReceiveTimeout(); /** * @return true if receive timeout is enabled. * * @see #enableReceiveTimeout */ boolean isReceiveTimeoutEnabled(); /** * @return the receive timeout value. If receive timeout is diabled * or not supported, this value is meaningless. * * @see #enableReceiveTimeout */ int getReceiveTimeout(); /** * Enables receive framing. * The supplied byte value in the input suggests the end of the received * frame, and read returns immediately. Only the low 8 bits of the * supplied value are significant. * * @param framingByte the frame delimiter * @throws gnu.io.UnsupportedCommOperationException * if receive framing is * not supported by the driver * @see #disableReceiveFraming */ void enableReceiveFraming(int framingByte) throws UnsupportedCommOperationException; /** * Disables receive framing. * * @see #enableReceiveFraming */ void disableReceiveFraming(); /** * @return true if receive framing is enabled. * * @see #enableReceiveFraming */ boolean isReceiveFramingEnabled(); /** * @return true if receive framing byte. If receive framing is diabled * or not supported, this value is meaningless. * * @see #enableReceiveFraming */ int getReceiveFramingByte(); /** * Sets the input buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setInputBufferSize(int size); /** * @return the input buffer size. * The driver may choose not to report correct values. */ int getInputBufferSize(); /** * Sets the output buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setOutputBufferSize(int size); /** * @return the output buffer size. * The driver may choose not to report correct values. */ int getOutputBufferSize(); } What do you think of that? Note the wishy washy nature of the spec: The driver may choose to ignore this method. Is that good enough for us? Thanks! - Doug From ra85551 at gmail.com Sun Mar 11 08:44:45 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Sun, 11 Mar 2007 17:44:45 +0300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hello, world! I am writing application that communicates with modem via AT commands. My OS is Linux Kubuntu Feisty Herd, to ensure that my application will run properly under Windows XP I installed VMWare server. When I tried to send AT command and evaluate modem answer under WinXP @ VMWare server, I actually didn't receive anything. I think that VM settings are right, because I do can communicate with modem by using standard HyperTerminall as well as I can do on native Windows. So, why RXTX doesn't work under VM, but works under Linux and pure Windows XP (i tested it there) well? The send/receive method code follows. private String sendATCommand(String command, final String waitFor, final boolean isRegex, boolean isAddCRLF, long timeout) throws BeaconConnectException { final long POLL_PERIOD = 100; final int BUFFER_SIZE = 512; final byte[] buffer = new byte[BUFFER_SIZE]; final InputStream serialInput; final OutputStream serialOutput; try { serialInput = serialPort.getInputStream(); if (command != null) { serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } } catch (IOException e) { throw new MyException("serial I/O error"); } TimerTask task = new TimerTask() { int offset = 0; int bytesRead; public synchronized void run() { try { if (serialInput.available() > 0) { bytesRead = serialInput.read(buffer, offset, BUFFER_SIZE - offset); } else { return; } } catch (IOException e) { // do nothing - maybe next time we'll read something } offset += bytesRead; if (waitFor != null) { String temporary = new String(buffer, 0, offset).trim(); if (isRegex && temporary.matches(waitFor) || temporary.contains(waitFor)) { cancel(); notify(); } } } }; Timer timer = new Timer(); timer.schedule(task, POLL_PERIOD, POLL_PERIOD); synchronized (task) { try { task.wait(timeout); task.cancel(); } catch (InterruptedException e) { } } //Cut off leading and trailing CRs, LFs and zeroes String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); System.out.println(response); return response; } -- Pavel Parkhomenko From tjarvi at qbang.org Sun Mar 11 11:48:22 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:48:22 -0600 (MDT) Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: On Sun, 11 Mar 2007, Pavel Parkhomenko wrote: > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. > > private String sendATCommand(String command, final String waitFor, > final boolean isRegex, boolean isAddCRLF, long timeout) > throws BeaconConnectException > { > final long POLL_PERIOD = 100; > final int BUFFER_SIZE = 512; > final byte[] buffer = new byte[BUFFER_SIZE]; > final InputStream serialInput; > final OutputStream serialOutput; > try > { > serialInput = serialPort.getInputStream(); > if (command != null) > { > serialOutput = serialPort.getOutputStream(); > if (isAddCRLF) > { > command += "\r\n"; > } > System.out.println(command); > serialOutput.write(command.getBytes()); > } > } > catch (IOException e) > { > throw new MyException("serial I/O error"); > } > > TimerTask task = new TimerTask() > { > int offset = 0; > int bytesRead; > public synchronized void run() > { > try > { > if (serialInput.available() > 0) > { > bytesRead = serialInput.read(buffer, offset, > BUFFER_SIZE - offset); > } > else > { > return; > } > } > catch (IOException e) > { > // do nothing - maybe next time we'll read something > } > offset += bytesRead; > if (waitFor != null) > { > String temporary = new String(buffer, 0, offset).trim(); > if (isRegex && temporary.matches(waitFor) || > temporary.contains(waitFor)) > { > cancel(); > notify(); > } > } > } > }; > > Timer timer = new Timer(); > timer.schedule(task, POLL_PERIOD, POLL_PERIOD); > synchronized (task) { > try > { > task.wait(timeout); > task.cancel(); > } > catch (InterruptedException e) > { > } > } > //Cut off leading and trailing CRs, LFs and zeroes > String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); > System.out.println(response); > return response; > } > > > Hi Pavel VMWare should not be a problem. I've used it in the past - though not with a modem. Make sure nothing else is using the modem. Then look in the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an example that should work. Note that modems could care less what OS is on top. If you are trying to match new lines to the OS and sending it to the mode for AT commands, thats probably a mistake. Also it would not hurt to print out the individual bytes that you are sending to make sure they did not get mangled along the path. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 11:55:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:55:48 -0600 (MDT) Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: On Sun, 11 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > I have been a proponent of a JSR that makes > use of RXTX. I have executed the proper agreements with Sun. > > At this point we are in the: > Early Draft Review of Draft Specifications Stage. > > The best thing to do is to enter the quiet period and create > a specification. The question of exactly how we, as a group, > want to approach this problem, remains open. > > Typically, we should have both a specification and a reference > implementation. Thus, it would be to our best advantage to have > a nice, stable, cross platform RXTX distro that adheres to the > groups specification. > > Now, from a specification standpoint, my personal view on the matter is > that we create a series of interfaces, with nice documentation (or at least > javadoc). > > Is this a good idea? Should we have a pure interface specification for > the communication API? > > There are several issues, in my mind, which still weigh on us. > Hot-pluggable dongles, long discovery process on pop-up ports, > lack of uniformity on device names, lack of uniformity on locking, > a precise understanding of how the SerialPortResourceManager > works (or even if we should have one). > > The more questions we answer in our reference implementation, the > better our specification will get. RXTX is a good working prototype, > but, I don't know if that is what we want to use for a specification. > > Here is what I have for a CommPortInterface: > */ > public interface CommPortInterface { Hi Doug, I can start going through the method interfaces later this week and giving feedback. I would suggest that the JSR should not be too generic in nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel drivers that intend to look like EIA232 ports at the kernel driver level. some ideas: EIA232PortInterface TermiosInterface SerialPortInterface Something that differentiates this from thing like USB, I2C, ... which should not have to deal with legacy serial claiming to be the comm api. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 12:52:19 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 12:52:19 -0600 (MDT) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: No news is good news with these posts. I'll start the process of pinging legal a week from Monday on my end if nobody has objections to the proposal. I just want to make sure everyone has time to raise objections. Obviously, anyone can fork from a previous version if they don't like the new license. I suspect we can avoid that though. On Sun, 4 Mar 2007, Trent Jarvi wrote: > > For those that are wondering what is going on here, this > next bit is the meat of the changes. We agreed a long time > ago to put this disclaimer in. We did a so so job. It was > in rxtx 2.0, not well written, ... So some groups using > rxtx that would like to ship rxtx so users don't need to > download, install, go to the mail-list to find why it failed, > ... Then their legal teams tell them section 5 paragraph 2 > is a show stopper. > > That was never the intent. > > > Now going through what remains... > >> and might need a (TM) suffix to make Sun happy. > > Added disclaimer at the ended 'all trademarks belong...' > >> * Line #15ff - static vs. dynamic linking - you did >> not transcribe the text from the "controlled >> interface exception" when writing this text - and >> this was good so, because these terms originally >> refer to the GPL rather than the LGPL. I think though, >> that these 4 lines are the most important ones and >> should thus be really really clear. I hope that I >> meet your original intent with the following >> suggestions: >> 1.) Instead of "A program.." it would be better to >> say "An exectuable.." in order to be closer to >> the LGPL text. > > OK. As you can see I was trying to adjust GNU text there > for the LGPL. > >> 2.) It would be better to say .. "by being dynamically >> linked with it" to clearly indicate that dynamic >> linking is meant. The matter of compilation is >> already covered by the LGPL so mentioning it again >> just leads to confusion. > > used dynamically linked terminology. > >> 3.) It would be better to say .. "is considered a >> work that uses the library in contrast to section >> 5 of the LGPL, so the terms of the LGPL do not >> apply to the resulting executable". > > I tried to address this more upfront with an intent statement. > Let me know if you have problems with it. I also tried to > make it a little more clear what was derived from the GNU > solution by moving the link location closer to GNU's suggestion. > >> >> Note that LGPL section 5 says: ..."is called a >> "work that uses the Library". Such a work, in isolation, >> is not a derivative work of the Library, and therefore >> falls outside the scope of this License." >> The next paragraph of the LGPL is exactly the problematic >> one that I hope is clarified by the exception terms you >> give. >> > > Thats the intent. Here is the combined fixes. Note that only the > material in /*-- --*/ is being touched. The new GPL license is > there but unmodified. > > > ------------------------ begin proposed new license ------------------- > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Lesser General Public > | License as published by the Free Software Foundation; either > | version 2.1 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Lesser General Public License for more details. > | > | An executable that contains no derivative of any portion of RXTX, but > | is designed to work with RXTX by being dynamically linked with it, > | is considered a "work that uses the Library" subject to the terms and > | conditions of the GNU Lesser General Public License. > | > | The following has been added to the RXTX License to remove > | any confusion about linking to RXTX. We want to allow in part what > | section 5, paragraph 2 of the LGPL does not permit in the special > | case of linking over a controlled interface. The intent is to add a > | Java Specification Request or standards body defined interface in the > | future as another exception but one is not currently available. > | > | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface > | > | As a special exception, the copyright holders of RXTX give you > | permission to link RXTX with independent modules that communicate with > | RXTX solely through the Sun Microsytems CommAPI interface version 2, > | regardless of the license terms of these independent modules, and to copy > | and distribute the resulting combined work under terms of your choice, > | provided that every copy of the combined work is accompanied by a complete > | copy of the source code of RXTX (the version of RXTX used to produce the > | combined work), being distributed under the terms of the GNU Lesser General > | Public License plus this exception. An independent module is a > | module which is not derived from or based on RXTX. > | > | Note that people who make modified versions of RXTX are not obligated > | to grant this special exception for their modified versions; it is > | their choice whether to do so. The GNU Lesser General Public License > | gives permission to release a modified version without this exception; this > | exception also makes it possible to release a modified version which > | carries forward this exception. > | > | You should have received a copy of the GNU Lesser General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > | All trademarks belong to their respective owners. > --------------------------------------------------------------------------*/ > > The original GNU Lesser General Public License Follows. > > > GNU LESSER GENERAL PUBLIC LICENSE > Version 2.1, February 1999 > > Copyright (C) 1991, 1999 Free Software Foundation, Inc. > 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > Everyone is permitted to copy and distribute verbatim copies > of this license document, but changing it is not allowed. > > [This is the first released version of the Lesser GPL. It also counts > as the successor of the GNU Library Public License, version 2, hence > the version number 2.1.] > > Preamble > > The licenses for most software are designed to take away your > freedom to share and change it. By contrast, the GNU General Public > Licenses are intended to guarantee your freedom to share and change > free software--to make sure the software is free for all its users. > > This license, the Lesser General Public License, applies to some > specially designated software packages--typically libraries--of the > Free Software Foundation and other authors who decide to use it. You > can use it too, but we suggest you first think carefully about whether > this license or the ordinary General Public License is the better > strategy to use in any particular case, based on the explanations below. > > When we speak of free software, we are referring to freedom of use, > not price. Our General Public Licenses are designed to make sure that > you have the freedom to distribute copies of free software (and charge > for this service if you wish); that you receive source code or can get > it if you want it; that you can change the software and use pieces of > it in new free programs; and that you are informed that you can do > these things. > > To protect your rights, we need to make restrictions that forbid > distributors to deny you these rights or to ask you to surrender these > rights. These restrictions translate to certain responsibilities for > you if you distribute copies of the library or if you modify it. > > For example, if you distribute copies of the library, whether gratis > or for a fee, you must give the recipients all the rights that we gave > you. You must make sure that they, too, receive or can get the source > code. If you link other code with the library, you must provide > complete object files to the recipients, so that they can relink them > with the library after making changes to the library and recompiling > it. And you must show them these terms so they know their rights. > > We protect your rights with a two-step method: (1) we copyright the > library, and (2) we offer you this license, which gives you legal > permission to copy, distribute and/or modify the library. > > To protect each distributor, we want to make it very clear that > there is no warranty for the free library. Also, if the library is > modified by someone else and passed on, the recipients should know > that what they have is not the original version, so that the original > author's reputation will not be affected by problems that might be > introduced by others. > > Finally, software patents pose a constant threat to the existence of > any free program. We wish to make sure that a company cannot > effectively restrict the users of a free program by obtaining a > restrictive license from a patent holder. Therefore, we insist that > any patent license obtained for a version of the library must be > consistent with the full freedom of use specified in this license. > > Most GNU software, including some libraries, is covered by the > ordinary GNU General Public License. This license, the GNU Lesser > General Public License, applies to certain designated libraries, and > is quite different from the ordinary General Public License. We use > this license for certain libraries in order to permit linking those > libraries into non-free programs. > > When a program is linked with a library, whether statically or using > a shared library, the combination of the two is legally speaking a > combined work, a derivative of the original library. The ordinary > General Public License therefore permits such linking only if the > entire combination fits its criteria of freedom. The Lesser General > Public License permits more lax criteria for linking other code with > the library. > > We call this license the "Lesser" General Public License because it > does Less to protect the user's freedom than the ordinary General > Public License. It also provides other free software developers Less > of an advantage over competing non-free programs. These disadvantages > are the reason we use the ordinary General Public License for many > libraries. However, the Lesser license provides advantages in certain > special circumstances. > > For example, on rare occasions, there may be a special need to > encourage the widest possible use of a certain library, so that it becomes > a de-facto standard. To achieve this, non-free programs must be > allowed to use the library. A more frequent case is that a free > library does the same job as widely used non-free libraries. In this > case, there is little to gain by limiting the free library to free > software only, so we use the Lesser General Public License. > > In other cases, permission to use a particular library in non-free > programs enables a greater number of people to use a large body of > free software. For example, permission to use the GNU C Library in > non-free programs enables many more people to use the whole GNU > operating system, as well as its variant, the GNU/Linux operating > system. > > Although the Lesser General Public License is Less protective of the > users' freedom, it does ensure that the user of a program that is > linked with the Library has the freedom and the wherewithal to run > that program using a modified version of the Library. > > The precise terms and conditions for copying, distribution and > modification follow. Pay close attention to the difference between a > "work based on the library" and a "work that uses the library". The > former contains code derived from the library, whereas the latter must > be combined with the library in order to run. > > GNU LESSER GENERAL PUBLIC LICENSE > TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION > > 0. This License Agreement applies to any software library or other > program which contains a notice placed by the copyright holder or > other authorized party saying it may be distributed under the terms of > this Lesser General Public License (also called "this License"). > Each licensee is addressed as "you". > > A "library" means a collection of software functions and/or data > prepared so as to be conveniently linked with application programs > (which use some of those functions and data) to form executables. > > The "Library", below, refers to any such software library or work > which has been distributed under these terms. A "work based on the > Library" means either the Library or any derivative work under > copyright law: that is to say, a work containing the Library or a > portion of it, either verbatim or with modifications and/or translated > straightforwardly into another language. (Hereinafter, translation is > included without limitation in the term "modification".) > > "Source code" for a work means the preferred form of the work for > making modifications to it. For a library, complete source code means > all the source code for all modules it contains, plus any associated > interface definition files, plus the scripts used to control compilation > and installation of the library. > > Activities other than copying, distribution and modification are not > covered by this License; they are outside its scope. The act of > running a program using the Library is not restricted, and output from > such a program is covered only if its contents constitute a work based > on the Library (independent of the use of the Library in a tool for > writing it). Whether that is true depends on what the Library does > and what the program that uses the Library does. > > 1. You may copy and distribute verbatim copies of the Library's > complete source code as you receive it, in any medium, provided that > you conspicuously and appropriately publish on each copy an > appropriate copyright notice and disclaimer of warranty; keep intact > all the notices that refer to this License and to the absence of any > warranty; and distribute a copy of this License along with the > Library. > > You may charge a fee for the physical act of transferring a copy, > and you may at your option offer warranty protection in exchange for a > fee. > > 2. You may modify your copy or copies of the Library or any portion > of it, thus forming a work based on the Library, and copy and > distribute such modifications or work under the terms of Section 1 > above, provided that you also meet all of these conditions: > > a) The modified work must itself be a software library. > > b) You must cause the files modified to carry prominent notices > stating that you changed the files and the date of any change. > > c) You must cause the whole of the work to be licensed at no > charge to all third parties under the terms of this License. > > d) If a facility in the modified Library refers to a function or a > table of data to be supplied by an application program that uses > the facility, other than as an argument passed when the facility > is invoked, then you must make a good faith effort to ensure that, > in the event an application does not supply such function or > table, the facility still operates, and performs whatever part of > its purpose remains meaningful. > > (For example, a function in a library to compute square roots has > a purpose that is entirely well-defined independent of the > application. Therefore, Subsection 2d requires that any > application-supplied function or table used by this function must > be optional: if the application does not supply it, the square > root function must still compute square roots.) > > These requirements apply to the modified work as a whole. If > identifiable sections of that work are not derived from the Library, > and can be reasonably considered independent and separate works in > themselves, then this License, and its terms, do not apply to those > sections when you distribute them as separate works. But when you > distribute the same sections as part of a whole which is a work based > on the Library, the distribution of the whole must be on the terms of > this License, whose permissions for other licensees extend to the > entire whole, and thus to each and every part regardless of who wrote > it. > > Thus, it is not the intent of this section to claim rights or contest > your rights to work written entirely by you; rather, the intent is to > exercise the right to control the distribution of derivative or > collective works based on the Library. > > In addition, mere aggregation of another work not based on the Library > with the Library (or with a work based on the Library) on a volume of > a storage or distribution medium does not bring the other work under > the scope of this License. > > 3. You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. To do > this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version 2, > instead of to this License. (If a newer version than version 2 of the > ordinary GNU General Public License has appeared, then you can specify > that version instead if you wish.) Do not make any other change in > these notices. > > Once this change is made in a given copy, it is irreversible for > that copy, so the ordinary GNU General Public License applies to all > subsequent copies and derivative works made from that copy. > > This option is useful when you wish to copy part of the code of > the Library into a program that is not a library. > > 4. You may copy and distribute the Library (or a portion or > derivative of it, under Section 2) in object code or executable form > under the terms of Sections 1 and 2 above provided that you accompany > it with the complete corresponding machine-readable source code, which > must be distributed under the terms of Sections 1 and 2 above on a > medium customarily used for software interchange. > > If distribution of object code is made by offering access to copy > from a designated place, then offering equivalent access to copy the > source code from the same place satisfies the requirement to > distribute the source code, even though third parties are not > compelled to copy the source along with the object code. > > 5. A program that contains no derivative of any portion of the > Library, but is designed to work with the Library by being compiled or > linked with it, is called a "work that uses the Library". Such a > work, in isolation, is not a derivative work of the Library, and > therefore falls outside the scope of this License. > > However, linking a "work that uses the Library" with the Library > creates an executable that is a derivative of the Library (because it > contains portions of the Library), rather than a "work that uses the > library". The executable is therefore covered by this License. > Section 6 states terms for distribution of such executables. > > When a "work that uses the Library" uses material from a header file > that is part of the Library, the object code for the work may be a > derivative work of the Library even though the source code is not. > Whether this is true is especially significant if the work can be > linked without the Library, or if the work is itself a library. The > threshold for this to be true is not precisely defined by law. > > If such an object file uses only numerical parameters, data > structure layouts and accessors, and small macros and small inline > functions (ten lines or less in length), then the use of the object > file is unrestricted, regardless of whether it is legally a derivative > work. (Executables containing this object code plus portions of the > Library will still fall under Section 6.) > > Otherwise, if the work is a derivative of the Library, you may > distribute the object code for the work under the terms of Section 6. > Any executables containing that work also fall under Section 6, > whether or not they are linked directly with the Library itself. > > 6. As an exception to the Sections above, you may also combine or > link a "work that uses the Library" with the Library to produce a > work containing portions of the Library, and distribute that work > under terms of your choice, provided that the terms permit > modification of the work for the customer's own use and reverse > engineering for debugging such modifications. > > You must give prominent notice with each copy of the work that the > Library is used in it and that the Library and its use are covered by > this License. You must supply a copy of this License. If the work > during execution displays copyright notices, you must include the > copyright notice for the Library among them, as well as a reference > directing the user to the copy of this License. Also, you must do one > of these things: > > a) Accompany the work with the complete corresponding > machine-readable source code for the Library including whatever > changes were used in the work (which must be distributed under > Sections 1 and 2 above); and, if the work is an executable linked > with the Library, with the complete machine-readable "work that > uses the Library", as object code and/or source code, so that the > user can modify the Library and then relink to produce a modified > executable containing the modified Library. (It is understood > that the user who changes the contents of definitions files in the > Library will not necessarily be able to recompile the application > to use the modified definitions.) > > b) Use a suitable shared library mechanism for linking with the > Library. A suitable mechanism is one that (1) uses at run time a > copy of the library already present on the user's computer system, > rather than copying library functions into the executable, and (2) > will operate properly with a modified version of the library, if > the user installs one, as long as the modified version is > interface-compatible with the version that the work was made with. > > c) Accompany the work with a written offer, valid for at > least three years, to give the same user the materials > specified in Subsection 6a, above, for a charge no more > than the cost of performing this distribution. > > d) If distribution of the work is made by offering access to copy > from a designated place, offer equivalent access to copy the above > specified materials from the same place. > > e) Verify that the user has already received a copy of these > materials or that you have already sent this user a copy. > > For an executable, the required form of the "work that uses the > Library" must include any data and utility programs needed for > reproducing the executable from it. However, as a special exception, > the materials to be distributed need not include anything that is > normally distributed (in either source or binary form) with the major > components (compiler, kernel, and so on) of the operating system on > which the executable runs, unless that component itself accompanies > the executable. > > It may happen that this requirement contradicts the license > restrictions of other proprietary libraries that do not normally > accompany the operating system. Such a contradiction means you cannot > use both them and the Library together in an executable that you > distribute. > > 7. You may place library facilities that are a work based on the > Library side-by-side in a single library together with other library > facilities not covered by this License, and distribute such a combined > library, provided that the separate distribution of the work based on > the Library and of the other library facilities is otherwise > permitted, and provided that you do these two things: > > a) Accompany the combined library with a copy of the same work > based on the Library, uncombined with any other library > facilities. This must be distributed under the terms of the > Sections above. > > b) Give prominent notice with the combined library of the fact > that part of it is a work based on the Library, and explaining > where to find the accompanying uncombined form of the same work. > > 8. You may not copy, modify, sublicense, link with, or distribute > the Library except as expressly provided under this License. Any > attempt otherwise to copy, modify, sublicense, link with, or > distribute the Library is void, and will automatically terminate your > rights under this License. However, parties who have received copies, > or rights, from you under this License will not have their licenses > terminated so long as such parties remain in full compliance. > > 9. You are not required to accept this License, since you have not > signed it. However, nothing else grants you permission to modify or > distribute the Library or its derivative works. These actions are > prohibited by law if you do not accept this License. Therefore, by > modifying or distributing the Library (or any work based on the > Library), you indicate your acceptance of this License to do so, and > all its terms and conditions for copying, distributing or modifying > the Library or works based on it. > > 10. Each time you redistribute the Library (or any work based on the > Library), the recipient automatically receives a license from the > original licensor to copy, distribute, link with or modify the Library > subject to these terms and conditions. You may not impose any further > restrictions on the recipients' exercise of the rights granted herein. > You are not responsible for enforcing compliance by third parties with > this License. > > 11. If, as a consequence of a court judgment or allegation of patent > infringement or for any other reason (not limited to patent issues), > conditions are imposed on you (whether by court order, agreement or > otherwise) that contradict the conditions of this License, they do not > excuse you from the conditions of this License. If you cannot > distribute so as to satisfy simultaneously your obligations under this > License and any other pertinent obligations, then as a consequence you > may not distribute the Library at all. For example, if a patent > license would not permit royalty-free redistribution of the Library by > all those who receive copies directly or indirectly through you, then > the only way you could satisfy both it and this License would be to > refrain entirely from distribution of the Library. > > If any portion of this section is held invalid or unenforceable under any > particular circumstance, the balance of the section is intended to apply, > and the section as a whole is intended to apply in other circumstances. > > It is not the purpose of this section to induce you to infringe any > patents or other property right claims or to contest validity of any > such claims; this section has the sole purpose of protecting the > integrity of the free software distribution system which is > implemented by public license practices. Many people have made > generous contributions to the wide range of software distributed > through that system in reliance on consistent application of that > system; it is up to the author/donor to decide if he or she is willing > to distribute software through any other system and a licensee cannot > impose that choice. > > This section is intended to make thoroughly clear what is believed to > be a consequence of the rest of this License. > > 12. If the distribution and/or use of the Library is restricted in > certain countries either by patents or by copyrighted interfaces, the > original copyright holder who places the Library under this License may add > an explicit geographical distribution limitation excluding those countries, > so that distribution is permitted only in or among countries not thus > excluded. In such case, this License incorporates the limitation as if > written in the body of this License. > > 13. The Free Software Foundation may publish revised and/or new > versions of the Lesser General Public License from time to time. > Such new versions will be similar in spirit to the present version, > but may differ in detail to address new problems or concerns. > > Each version is given a distinguishing version number. If the Library > specifies a version number of this License which applies to it and > "any later version", you have the option of following the terms and > conditions either of that version or of any later version published by > the Free Software Foundation. If the Library does not specify a > license version number, you may choose any version ever published by > the Free Software Foundation. > > 14. If you wish to incorporate parts of the Library into other free > programs whose distribution conditions are incompatible with these, > write to the author to ask for permission. For software which is > copyrighted by the Free Software Foundation, write to the Free > Software Foundation; we sometimes make exceptions for this. Our > decision will be guided by the two goals of preserving the free status > of all derivatives of our free software and of promoting the sharing > and reuse of software generally. > > NO WARRANTY > > 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO > WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. > EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR > OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY > KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE > IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE > LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME > THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. > > 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN > WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY > AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU > FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR > CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE > LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING > RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A > FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF > SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH > DAMAGES. > > END OF TERMS AND CONDITIONS > > How to Apply These Terms to Your New Libraries > > If you develop a new library, and you want it to be of the greatest > possible use to the public, we recommend making it free software that > everyone can redistribute and change. You can do so by permitting > redistribution under these terms (or, alternatively, under the terms of the > ordinary General Public License). > > To apply these terms, attach the following notices to the library. It is > safest to attach them to the start of each source file to most effectively > convey the exclusion of warranty; and each file should have at least the > "copyright" line and a pointer to where the full notice is found. > > > Copyright (C) > > This library is free software; you can redistribute it and/or > modify it under the terms of the GNU Lesser General Public > License as published by the Free Software Foundation; either > version 2.1 of the License, or (at your option) any later version. > > This library is distributed in the hope that it will be useful, > but WITHOUT ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > Lesser General Public License for more details. > > You should have received a copy of the GNU Lesser General Public > License along with this library; if not, write to the Free Software > Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > > Also add information on how to contact you by electronic and paper mail. > > You should also get your employer (if you work as a programmer) or your > school, if any, to sign a "copyright disclaimer" for the library, if > necessary. Here is a sample; alter the names: > > Yoyodyne, Inc., hereby disclaims all copyright interest in the > library `Frob' (a library for tweaking knobs) written by James Random Hacker. > > , 1 April 1990 > Ty Coon, President of Vice > > That's all there is to it! > ------------------------ end of proposed license ------------------ > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From gjhanna at gmail.com Sun Mar 11 14:21:17 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Mon, 12 Mar 2007 09:21:17 +1300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hi Pavel, We are using RXTX under VMWare server in production, quite satisfactorily. We're using Red Hat Enterprise Server 4, and ... Whatever the "enterprise" VMWare product is. Regards, Greg H > Subject: [Rxtx] RXTX under VMWare server > To: rxtx at qbang.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. [ ... snip ... ] -- Pavel Parkhomenko -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070311/4cebb6f9/attachment-0005.html From gergg at cox.net Sun Mar 11 23:39:19 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 12 Mar 2007 00:39:19 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: <45F4E787.6050502@cox.net> Trent Jarvi wrote: > I can start going through the method interfaces later this week and giving > feedback. I would suggest that the JSR should not be too generic in > nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel > drivers that intend to look like EIA232 ports at the kernel driver level. > > some ideas: > > EIA232PortInterface > TermiosInterface > SerialPortInterface > > Something that differentiates this from thing like USB, I2C, ... which > should not have to deal with legacy serial claiming to be the comm api. I'm going to throw out a suggestion, which I am mostly serious about. What would happen if we took the appropriate bits of the J2ME connector API, and just used that as the new COMM API so that finally JSE and JME had a common foundation for these kinds of things? Gregg Wonderly From ra85551 at gmail.com Mon Mar 12 09:08:37 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Mon, 12 Mar 2007 18:08:37 +0300 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Should any application use the modem, HyperTerminal won't be able to talk to the modem. But it actually can send and receive AT comands, while my application cannot :-( > Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Thansk for the reference. I examined that example and found that there's no significant differences between my read/write implementation and that one, except that SimpleSnuV1 listens for serialEvent's, but not for sake of data retrieval, just for printing them out - I don't know why ;-) > Note that modems could care less what OS is on top. If you are trying to > match new lines to the OS and sending it to the mode for AT commands, > thats probably a mistake. I do send strings to serial port, not to OS, and do try to get answers back. If it is the mistake, what's the right way? > Also it would not hurt to print out the > individual bytes that you are sending to make sure they did not get > mangled along the path. Yeah, I am printing these bytes before doing write, but it means that I only see what I intend to write. How can I ensure that these bytes have gone out of the box and reached my modem? BTW, I found that my send/receive method is complex enough, so I've rewritten it. Please, see the following code and point any mistakes, because I don't know where can they remain yet. private static final int LARGE_TIMEOUT = 15000; private static final int SMALL_TIMEOUT = 500; ... private String sendATCommand(String command, String waitFor, boolean isRegex, boolean isAddCRLF) throws BeaconConnectException { byte[] buffer = new byte[512]; int offset; String result = ""; try { if (waitFor != null) { serialPort.enableReceiveTimeout(LARGE_TIMEOUT); } else { serialPort.enableReceiveTimeout(SMALL_TIMEOUT); } if (command != null) { OutputStream serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } offset = 0; InputStream serialInput = serialPort.getInputStream(); while (serialInput.available() != -1) { int bytesRead = serialInput.read(buffer, offset, buffer.length - offset); if (bytesRead == 0) { break; } offset += bytesRead; result = new String(buffer, 0, offset).trim(); if (waitFor != null) { System.out.println(result); if (isRegex && result.matches(waitFor) || result.contains(waitFor)) { break; } } } } catch (UnsupportedCommOperationException e) { throw new MyException("unsupported operation"); } catch (IOException e) { throw new MytException("serial I/O error"); } return result; } -- Pavel Parkhomenko From clayno at hotpop.com Thu Mar 15 02:47:34 2007 From: clayno at hotpop.com (Christopher Layno) Date: Thu, 15 Mar 2007 16:47:34 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi, we're using the latest release of rxtx (2.1-7r2) for our system that has two applications using the library. one application sends requests to the modem while the other simply checks the modem status. we deployed our system on a pentium machine with red hat linux 9.0 installed. now the problem arises when these two applications try to access the same modem at the same time. one of them will eventually have to throw the PortInUseException as shown below: 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException gnu.io.PortInUseException: root PID = 743 Program = java root PID = 743 Program = java root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) this was expected. what we didn't expect though was that if we repeat the scenario 5 times, always 5 times, the application would also throw a VM error: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4473CD21 Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so Current Java thread: at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) - locked <0x44cfd4c8> (a gnu.io.CommPortIdentifier) at ************ at ************ - locked <0x4476a468> (a **********) at ************ at ************ at ************ at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java :261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages( TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run( TCPTransport.java:701) at java.lang.Thread.run(Thread.java:534) note: i replaced some sensitive data with asterisks our team has looked everywhere on the internet, including your mail archives, for a solution to this problem but to no avail. i really hope you could help us out on this one. thanks in advance! best regards, chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070315/1936460a/attachment-0005.html From tjarvi at qbang.org Fri Mar 16 04:30:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 04:30:25 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: On Thu, 15 Mar 2007, Christopher Layno wrote: > hi, > > we're using the latest release of rxtx (2.1-7r2) for our system that has two > applications using the library. one application sends requests to the modem > while the other simply checks the modem status. we deployed our system on a > pentium machine with red hat linux 9.0 installed. > > now the problem arises when these two applications try to access the same > modem at the same time. one of them will eventually have to throw the > PortInUseException as shown below: > > 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException > gnu.io.PortInUseException: root PID = 743 Program = java root PID = > 743 Program = java root PID = 743 Program = ??? root PID = 743 Program > = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root > PID = 743 Program = ??? root PID = 743 Program = ??? > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > > this was expected. what we didn't expect though was that if we repeat the > scenario 5 times, always 5 times, the application would also throw a VM > error: > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x4473CD21 > Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 > Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so > > Current Java thread: > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) Hi Chris The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. The code is originally by Werner Almesberger. He gave us permission to use it in rxtx. You might look at what has changed since 1998 in his fuser application. Or you can just do like other OSs and do the following in fuserImp.c JNIEXPORT jstring JNICALL Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv *env, jobject obj, jstring arg) { return (*env)->NewStringUTF(env, "Unknown Application"); } It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. -- Trent Jarvi tjarvi at qang.org From Adrien.TOS at ingenico.com Fri Mar 16 05:11:12 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Fri, 16 Mar 2007 12:11:12 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903CBC312@frsnprexc1.usr.ingenico.loc> Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070316/972ab214/attachment-0005.html From joachim at buechse.de Fri Mar 16 05:13:24 2007 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 16 Mar 2007 12:13:24 +0100 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. From tjarvi at qbang.org Fri Mar 16 16:36:29 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 16:36:29 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Fri Mar 16 16:02:23 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 16 Mar 2007 18:02:23 -0400 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Not all platforms are Unix based. Also mixing native library usage and command-line calls is not an elegant solution, IMHO. One or the other, but not both. Andre On 16-Mar-07, at 07:13 , Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is > trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We >> only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From clayno at hotpop.com Sun Mar 18 22:17:28 2007 From: clayno at hotpop.com (Christopher Layno) Date: Mon, 19 Mar 2007 12:17:28 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi everyone, thank you so much for your replies. they were really helpful. anyway, before i sent the email, my team was already implementing a temporary solution by using joachim's suggestion. we invoked a lsof command from our java code although i share the same concern with trent and andre-john about portability issues. that's why i said it's just temporary. my superiors have yet to approve our bug fix. so my question now is this: is recompiling the rxtx source code the only way to solve this problem? because if it's the only solution, then i think my superiors would rather have a new release from the rxtx community itself that fixes this bug(?) rather than have my team recompile the source code. best regards, chris Trent Jarvi wrote: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. ... It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070318/237463b2/attachment-0005.html From tjarvi at qbang.org Mon Mar 19 16:20:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Mar 2007 16:20:52 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: Hi Chris I can compile a new version after the 21st if you do not feel comfortable doing so. Please send me an email reminder off-line then. On Mon, 19 Mar 2007, Christopher Layno wrote: > hi everyone, > > thank you so much for your replies. they were really helpful. > > anyway, before i sent the email, my team was already implementing a > temporary solution by using joachim's suggestion. > we invoked a lsof command from our java code although i share the same > concern with trent and andre-john about > portability issues. that's why i said it's just temporary. my superiors have > yet to approve our bug fix. > > so my question now is this: is recompiling the rxtx source code the only way > to solve this problem? because if it's the only > solution, then i think my superiors would rather have a new release from the > rxtx community itself that fixes this bug(?) > rather than have my team recompile the source code. > > best regards, > > chris > > Trent Jarvi wrote: > > Hi Joachim > > It would be nice to have that functionality but calling the program > introduces too many issues imho. Explaining to someone why rxtx invoked a > rogue lsof does not sound very interesting. > > On Fri, 16 Mar 2007, Joachim Buechse wrote: > > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: > > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. > > _______________________________________________ > Rxtx mailing list > Rxtx 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 Eric.Arseneau at sun.com Tue Mar 20 11:47:33 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Tue, 20 Mar 2007 10:47:33 -0700 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 Message-ID: <46001E35.9040608@sun.com> Anyone have any experience with RXTX working with JDK 6 on other platforms ? From mm at UDel.Edu Tue Mar 20 12:18:29 2007 From: mm at UDel.Edu (Mike Markowski) Date: Tue, 20 Mar 2007 14:18:29 -0400 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 In-Reply-To: <46001E35.9040608@sun.com> References: <46001E35.9040608@sun.com> Message-ID: <46002575.4000306@udel.edu> Eric Arseneau wrote: > Anyone have any experience with RXTX working with JDK 6 on other platforms ? I'm using 32 bit intel, gentoo linux, jdk6 with no problems. My applications only use a serial port, though, nothing on the parallel port. Mike From falko.guderian at gmx.de Wed Mar 21 08:17:35 2007 From: falko.guderian at gmx.de (Falko Guderian) Date: Wed, 21 Mar 2007 15:17:35 +0100 Subject: [Rxtx] RXTX binaries for SH4 Message-ID: <46013E7F.40102@gmx.de> Dear developers, I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no possiblities to compile the source code. Better, I'm not able to do this at the moment. Can you provide me with rxtxSerial.dll (SH4) in the rxtx-2.1-8-testing version? (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) The reason for the testing version is I need custom baud rates. Thanks for help. Kind regards, Falko Guderian From tjarvi at qbang.org Wed Mar 21 21:38:37 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Mar 2007 21:38:37 -0600 (MDT) Subject: [Rxtx] RXTX binaries for SH4 In-Reply-To: <46013E7F.40102@gmx.de> References: <46013E7F.40102@gmx.de> Message-ID: On Wed, 21 Mar 2007, Falko Guderian wrote: > Dear developers, > > I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no > possiblities to compile the source code. Better, I'm not able to do this > at the moment. Can you provide me with rxtxSerial.dll (SH4) in the > rxtx-2.1-8-testing version? > (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) > > The reason for the testing version is I need custom baud rates. > > Thanks for help. > Hi Falko WinCE binary format is not supported by gcc. That makes compiling limited to those familiar with the WinCE tools. I hope someone is able to provide them for you but it is not likely. WinCE has been compiled by others in the past but rxtx.org builds have never included WinCE. There is some information with the source concerning WinCE builds if you decide to do it. We can share your results too if you like. The source in the WinCE has never been updated for the custom baud rate. That would need changes from the main source I presume. If you look at the source, you will note that Michal Hobot created a mini fork in the source to handle wince but it has not been updated for 3 years. -- Trent Jarvi tjarvi at qbang.org From Adrien.TOS at ingenico.com Thu Mar 22 07:08:55 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Thu, 22 Mar 2007 14:08:55 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Hi everybody, Do you have any comments on this issue? Thanks! AT ________________________________ De : Adrien TOS Envoy? : vendredi 16 mars 2007 12:11 ? : 'rxtx at qbang.org' Cc : Adrien TOS Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070322/2306c538/attachment-0005.html From jeremy.reeve at zen.co.uk Mon Mar 19 07:36:04 2007 From: jeremy.reeve at zen.co.uk (Jeremy S. Reeve) Date: Mon, 19 Mar 2007 13:36:04 +0000 Subject: [Rxtx] rxtx failing to compile on Fedora Core 6 Message-ID: <1174311364.21865.6.camel@d9thc> When trying to compile latest source : rxtx-2.1-7r2 I get the following when running configure: ---------------- checking os.version 2.6.18-1.2200.fc5smp WARNING: configure is having a hard time determining which directory contains the file jni_md.h. Edit Makefile and fix the variable JAVANATINC to point to the correct directory. The following options are available: /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/ /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/linux/ If there are more than one option available the first was selected. WARNING: Kernel include files do not match the current kernel configure: creating ./config.status ------------------------ which seems OK checking the resultant Makefile but when attempting to build with gmake install I get the following output : ---------------------- 34 problems (34 warnings)/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/javah -classpath .:/home/jsr/rxtxsrc/rxtx-2.1-7r2:/home/jsr/rxtxsrc/rxtx-2.1-7r2/src:/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/ext/RXTXcomm.jar -d i686-pc-linux-gnu -jni `(for i in CommDriver CommPortEnumerator CommPortIdentifier CommPort CommPortOwnershipListener Configure I2C I2CPortEvent I2CPortEventListener I2CPort LPRPort NoSuchPortException ParallelPortEvent ParallelPortEventListener ParallelPort PortInUseException Raw RawPortEvent RawPortEventListener RawPort RS485 RS485PortEvent RS485PortEventListener RS485Port RXTXCommDriver RXTXPort RXTXVersion SerialPortEvent SerialPortEventListener SerialPort UnsupportedCommOperationException UnSupportedLoggerException Zystem;do \ if grep > /dev/null native.* \( /home/jsr/rxtxsrc/rxtx-2.1-7r2/./src/$i.java; then \ echo gnu.io.$i; \ fi; \ done)` i686-pc-linux-gnu/gnu_io_CommPortIdentifier.h: No such file or directory make: *** [/home/jsr/rxtxsrc/rxtx-2.1-7r2/gnu/io/CommDriver.class] Error 1 ------------------------ Any ideas or pointers? Regards, Jeremy From tjarvi at qbang.org Sat Mar 24 08:12:54 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 Mar 2007 08:12:54 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > From Adrien.TOS at ingenico.com Sat Mar 24 11:53:22 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Sat, 24 Mar 2007 18:53:22 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> I do not have the threshold setting enabled, I have explicitely disabled it with: port_.disableReceiveThreshold(); I have also run the same tests with the threshold setting enabled, but they also fail in the same way as described below. So it seems there is a problem with timeout handling on Win32? ________________________________ From: rxtx-bounces at qbang.org on behalf of Trent Jarvi Sent: Sat 3/24/2007 3:12 PM To: RXTX Developers and Users Subject: Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 8312 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20070324/f9e39c9b/attachment-0005.bin From greg.johnson at manchester.ac.uk Sun Mar 25 13:41:36 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Sun, 25 Mar 2007 21:41:36 +0200 Subject: [Rxtx] Mac intel weirdness Message-ID: Hi folks, I'm trying to get rxtx to work on my macbook pro with a USB-serial dongle on it. I am using the 2.1-8 code from the CVS (though it seems to report itself as 2.1-7: makes it difficult to prove to oneself that the changes have 'taken'! - line 4210 in SerialImp.c, line 40 in RXTXVersion.java) I am trying the 2.1-8 because of horrible lock problems in 2.1-7. However, the serialport closure code seems to be broken - it won't close because it believes the (previously opened!) port doesn't exist. Here is what I'm trying: 0. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "false" 1. Open a port Serialport serialport = (SerialPort) commportidentifier.open ("test",100); 2. Talk to a device ... 3. Close port serialport.close(); 4. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "true" - why is this? 5. Try to reopen port Serialport serialport2 = (SerialPort) commportidentifier.open("test", 100); throws PortInUseException. I've dug around a bit in the source, and it seems the SerialPort.close () should call the CommPortIdentifier.internalClosePort() (line 67 of CommPort.java). However, I crash out with the NoSuchPortException when getPortIdentifier is called. Which seems quite weird to me, seeing as it is called on this - which was create just beforehand. Does anyone know how to fix this? Cheers, greg From knute at frazmtn.com Sat Mar 24 10:32:38 2007 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 24 Mar 2007 09:32:38 -0700 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc>, Message-ID: <4604F036.17833.135298@knute.frazmtn.com> > >The behavior of timeout depends upon the setting of the threshold. Do you >have the threshold setting? > This is the same bug I reported last fall. There was a fellow that sent me an email asking if it had been fixed. I told him I didn't think so. He got somebody to write a fix for him but I have not been able to contact him again for the actual changes. The inaccurate timeout and the failure of blocking when no timeouts are set is a serious bug in my humble opinion and renders the software unusable for my applications. I'd really like to have an alternative to the Sun comm api but there just isn't one that I know of. -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Mar 26 16:17:00 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 26 Mar 2007 16:17:00 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> Message-ID: >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. From ra85551 at gmail.com Tue Mar 27 10:18:36 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Tue, 27 Mar 2007 20:18:36 +0400 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Ultimately I found a solution. At first, that wasn't actually the VMWare + WinXP + RXTX issue, that was WinXP + RXTX issue. But on pure XP it sometimes workes, sometimes not, while under VMWare I had never seen my snippet working at all. SimpleSnuV1.java would not help me, because there is only one line I missed, and SimpleSnuV1.java also doesn't contain it! It is as follows: serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_OUT | SerialPort.FLOWCONTROL_RTSCTS_IN); Thank you for your attention. -- Pavel Parkhomenko From griff at op.pl Wed Mar 28 01:28:19 2007 From: griff at op.pl (griff@op.pl) Date: Wed, 28 Mar 2007 09:28:19 +0200 Subject: [Rxtx] No blocking read on Windows. Message-ID: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/5d07d571/attachment-0005.html -------------- next part -------------- Hi, I have problem that InputStram.read() (SerialPort)?returns -1 instead blocking and waiting for data. I found that this problem was ?known in 2005 : ? >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > >> Hi Trent >> >> Thanks for the fast response. >> Here's a Q&D test program for the blocking read on windows that just >> attempts to read one byte, and prints the resulting byte. On my system it >> returns -1, where I expect that it keeps waiting for data. >> >This isn't happening on Linux so the bug is in src/termios.c.? I'll have >something this weekend to fix that. I'm using RXTX 2.1.7r2 and the problem still is here. Im using Windows XP and java 1.5 disableReciveTimeout() and disableReciveTreshhold() dont help. ? best regards ? Piotr Zielniok From Adrien.TOS at ingenico.com Wed Mar 28 01:40:46 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Wed, 28 Mar 2007 09:40:46 +0200 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903E88880@frsnprexc1.usr.ingenico.loc> Looking at the code, it seems there is no support for infinite timeout? And maybe the count++ < 20 condition is breaking out of the loop too early? The only condition to break out of the loop should either be the timeout has expired or the number of requested bytes has been received. -----Message d'origine----- De : rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] De la part de Trent Jarvi Envoy? : mardi 27 mars 2007 00:17 ? : RXTX Developers and Users Objet : Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From j.kenneth.gentle at acm.org Wed Mar 28 06:44:15 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 28 Mar 2007 08:44:15 -0400 Subject: [Rxtx] No blocking read on Windows. In-Reply-To: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> References: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> Message-ID: <200703281844.l2SIiITW028614@qbang.org> Just another "ME TOO!" - I'm seeing this problem on Windows XP, jre for windows XP/Embedded. I cranked receiveTimeout up to Integer.MAX_INT, but it doesn't seem to wait that long At 03:28 2007-03-28, you wrote: >Hi, >I have problem that InputStram.read() (SerialPort) returns -1 >instead blocking and waiting for data. I found that this problem >was known in 2005 : > > >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > > > >> Hi Trent > >> > >> Thanks for the fast response. > >> Here's a Q&D test program for the blocking read on windows that just > >> attempts to read one byte, and prints the resulting byte. On my system it > >> returns -1, where I expect that it keeps waiting for data. > >> > > >This isn't happening on Linux so the bug is in src/termios.c. I'll have > >something this weekend to fix that. > >I'm using RXTX 2.1.7r2 and the problem still is here. >Im using Windows XP and java 1.5 >disableReciveTimeout() and disableReciveTreshhold() dont help. > >best regards > >Piotr Zielniok > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From greg.johnson at manchester.ac.uk Wed Mar 28 14:43:29 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Wed, 28 Mar 2007 22:43:29 +0200 Subject: [Rxtx] Cannot close and reopen serial port Message-ID: <377F9765-7A9D-4CE9-9176-FFB63A2594F0@manchester.ac.uk> Dear all, It appears I cannot close a port properly: SerialPort serialport = portid.open("myprog",100); // do some stuff, all works fine serialport.close(); // all seems fine but... SerialPort sp2 = portid.open("myprog",100); throws PortInUseException. And when I dig into the rxtx code, I find in CommPort.java, in close(): CommPortIdentifier cp = CommPortIdentifier.getPortIdentifier(this); (line 64 or there abouts) but this throws a NoSuchPortException which is caught but ignored (line 74ish). Can anyone suggest how this could happen: a port that was valid, opened, and used, throws a NSPE when it comes to closing it? I'm pulling my (remaining) hair out over this one! Cheers, greg PS And thanks for RXTX - it's great to have! PPS (21.-7. winxp/osx both, java 1.5) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/c28852fc/attachment-0005.html From rxtx at vrijheidslaan.net Fri Mar 30 16:52:50 2007 From: rxtx at vrijheidslaan.net (Rob) Date: Fri, 30 Mar 2007 22:52:50 -0000 Subject: [Rxtx] Cvs Question Message-ID: <61896.80.126.150.87.1175295162.squirrel@webmail.provalue.nl> Hi There, Im trying to get the latest version to work on mac osx. Problem is that i can't checkout version 2.1.8. Probably my fault but can some one please give me the alternative commands for: [user at myhost]$ export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot [user at myhost]$ cvs login Thanx, Rob From ra85551 at gmail.com Thu Mar 1 03:47:06 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Thu, 1 Mar 2007 13:47:06 +0300 Subject: [Rxtx] enableReceiveTimeout() issue Message-ID: Hello, world! I found a limitation of 16300 ms for CommPort's enableReceiveTimeout() method, while in original javax.comm docs there are no any references to that. Is that a bug or feature? I actually need longer timeouts sometimees. -- Pavel Parkhomenko From lyon at docjava.com Thu Mar 1 07:54:17 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 01 Mar 2007 09:54:17 -0500 Subject: [Rxtx] parametric singleton design pattern In-Reply-To: References: <22d55aea0702081207q5e7f6785l352d498d6f5f9fb1@mail.gmail.com> <22d55aea0702100034o3bcf42f3j1d1a6257029a67b0@mail.gmail.com> Message-ID: Hi All, I have been thinking about the use of a design pattern to cache resources that are consumed by processes. Toward that end, I have arrived at a parametric singleton design pattern, which I mentioned on this list some time ago. The idea has been published at: http://www.jot.fm/issues/issue_2007_03/column2 I can't help but think that there should be an API available for dealing with the tracking of serial port usage. Perhaps it is a kind of resource manager called the: SerialPortManager basic prototypes already exist in this vain. See, for example: http://www.ce.rit.edu/research/projects/2005_fall/rt_poolsystem/doc/PoolMon/SerialPortManager.html http://www.eventhelix.com/RealtimeMantra/PatternCatalog/serial_port_design_pattern.htm And others shown by a google search on "SerialPortManager" Cheers! - Doug From Eric.Arseneau at sun.com Thu Mar 1 10:15:03 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:15:03 -0800 Subject: [Rxtx] Any known Java 6 issues with RXTX 2.1-7r2 ? Message-ID: <45E70A17.1060206@sun.com> I just did a test on a recent build of Solaris 11 x86 and it seems that I can connect to my serial device fine when Java 5 is the default, but when Java 6 is the default, no go. Any information ? From Eric.Arseneau at sun.com Thu Mar 1 10:19:58 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:19:58 -0800 Subject: [Rxtx] Mac OS X and missing data Message-ID: <45E70B3E.7040908@sun.com> We have a device which is USB based but presents itself as a serial port to a machine. On my MacBook Pro I can get excellent throughput if I get my device to send data as quickly as possible. On the desktop side, if I do an type of disk IO to log the data I get, I end up with some missing data at some point. I hooked up a USB analyzer and did confirm that all the data is sent as expected to the desktop from the device. I found a work around for this, buffer the data in memory and only write the data out when I've received it all. However, when the same code and same device is attempted on a co-workers MacBook Pro (same hardware specs), I get errors and must slow down dramatically the device side's sending of data. Any ideas/recommendations on what I can do to get rid of this error ? From what I can tell, it seems that RXTX is not able to wake up to the interrupts coming in indicating data is ready, quickly enough, is there anything I can do ? From chinkaiw at hotmail.com Fri Mar 2 00:57:43 2007 From: chinkaiw at hotmail.com (Wang Chinkai) Date: Fri, 02 Mar 2007 07:57:43 +0000 Subject: [Rxtx] dynamic detect rs232 port Message-ID: Hi all I have a question about detecting rs232 port dynamicly. I have to aceess some port and detect rs232 port at the same time. Some usb device simulates rs232 port , and I can not know what the port name it gets until it connects,so I have to detect it dynamic,but I have to access another rs232 device at the same time. I found a problem. If I use CommPortIdentifier.getPortIdentifiers() to get new port list , and the other rs232 access function will not close port correctly. So , How can I solve it . Thanks. _________________________________________________________________ ?? 2GB ???? Windows Live Mail ????????????? http://ideas.live.com/programpage.aspx?versionid=5d21c51a-b161-4314-9b0e-4911fb2b2e6d From eu259473 at tele2.it Fri Mar 2 06:16:40 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 02 Mar 2007 14:16:40 +0100 Subject: [Rxtx] rxtx on HP tru 64 unix Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070302/706c7a70/attachment-0006.html From tjarvi at qbang.org Fri Mar 2 08:39:33 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 08:39:33 -0700 (MST) Subject: [Rxtx] rxtx on HP tru 64 unix In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, "Giuseppe Marchese" wrote: > Hi > > I try to install rxtx on hp tru 64 but make fails, > There are somebody that do the same and work. > > > Sorry for may english! > > Hi Giuseppe Could you provide a log of the failure? script ./configure make # use gnu make exit The information will be in the typescript created. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 2 19:56:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 19:56:52 -0700 (MST) Subject: [Rxtx] dynamic detect rs232 port In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, Wang Chinkai wrote: > Hi all > > I have a question about detecting rs232 port dynamicly. > > I have to aceess some port and detect rs232 port at the same time. > Some usb device simulates rs232 port , and I can not know > what the port name it gets until it connects,so I have to detect it > dynamic,but I have to access > another rs232 device at the same time. > > I found a problem. Hi Wang This is a known problem. The code is braindead there. In fact there needs to be events even in a rudamentary way when you add a usb dongle. I'm burried in tasks not far from rxtx but not in rxtx. I can't get to the problem but we would accept patches if you dig into it. [I'm getting to the license question earlier too; I don't have another 10%] -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Fri Mar 2 23:19:01 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 01:19:01 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Hi, Under ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable USB -> serial converter(using virtual com port drivers), with using example code pretty much straight out of http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port opens fine, enumerations all work, etc. My application calls for a large amount of data to be transferred in a short amount of time at 2,000,000 baud. My hardware sends approximately 15,232 bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL converter work fine, and the application works using C++. In C++, I do a hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); to open the port, and a boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); to read the port. The variable buffer fills with the 15238 bytes, and returns. If I do a resultz = is.read(cbuf,0,15238); in java with RXTX where is = new BufferedReader(new InputStreamReader(port.getInputStream())); and where resultz is an int, and cbuf is a char [] cbuf, resultz gets EXACTLY 3968 bytes the first time called. If I call it multiple times, I get roughly 11k total(less than what is sent), never more than the 3968 bytes per is.read() call. My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 bytes. I've played with inputbuffersize, receive threshold, receivetimeout, and so on. The FTDI virtual com port drivers that I'm using are rock solid, and have had zero problems with them using a variety of applications, some of my own, some professionally written, etc. No flow control is used anyplace, no RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. No exceptions are being thrown. What am I doing wrong, and what I can adjust to receive the full 15k bytes in one single read? Thanks! Keith From Eric.Arseneau at sun.com Fri Mar 2 23:32:07 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Fri, 02 Mar 2007 22:32:07 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <45E91667.20501@sun.com> This is the same type of thing that is happening to me on Mac OS X and does not seem to behave the same on different machines. I posted a day or two ago on this with subject "Mac OS X and missing data". Would love to hear if there is a solution to this :) From tjarvi at qbang.org Sat Mar 3 10:54:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 10:54:17 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > Hi, > > Under > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable > USB -> serial converter(using virtual com port drivers), with using example > code pretty much straight out of > http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port > opens fine, enumerations all work, etc. > > My application calls for a large amount of data to be transferred in a short > amount of time at 2,000,000 baud. My hardware sends approximately 15,232 > bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL > converter work fine, and the application works using C++. > > In C++, I do a > > hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, > OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); > > to open the port, and a > > boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); > > to read the port. > > The variable buffer fills with the 15238 bytes, and returns. > > If I do a > > resultz = is.read(cbuf,0,15238); in java with RXTX > > where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > > and where resultz is an int, and cbuf is a char [] cbuf, resultz gets > EXACTLY 3968 bytes the first time called. If I call it multiple times, I get > roughly 11k total(less than what is sent), never more than the 3968 bytes > per is.read() call. > > My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 > bytes. > > I've played with inputbuffersize, receive threshold, receivetimeout, and so > on. The FTDI virtual com port drivers that I'm using are rock solid, and > have had zero problems with them using a variety of applications, some of my > own, some professionally written, etc. No flow control is used anyplace, no > RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. > > No exceptions are being thrown. > > What am I doing wrong, and what I can adjust to receive the full 15k bytes > in one single read? > > Thanks! > Hi Keith I would expect a 20 meg application is going to have different behavior with the OS than a smaller application with respect to the kernel memory managment, schedualing, ... Something subtle could be causing problems. With respect to the recieve timeout and threshold, if you set the timeout to zero and the threshold to the size of data you expect, read should not return until it get that data. You may try with a stand alone application that tests just that with the C/C++ API. If the read is returning with less data when tested for short reads, you have found a bug in the device driver more than likely. The USB dongle vendor would probably be interested in knowing about this. As mentioned, these devices are getting very good; almost bug free. I suspect you found a bug though if you did use the threshold and timeout properly. The missing data is typical when not using flow control. When the OS buffering fills, the hardware will start dropping bytes. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:38:52 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:38:52 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> update: I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now instead of 3968. This makes sense. 128 bytes of overhead + 3968 bytes of data = 4096 transfer size 32 bytes of overhead + 992 bytes of data = 1024 transfer size. 1/4 the data = 1/4 the overhead. I rearranged my reading like so: resultz = is.read(cbuf,0,3968); resultz = is.read(cbuf,3968,3968); resultz = is.read(cbuf,7936,3968); while (!(is.ready())); // wait for ready resultz = is.read(cbuf,11904,3334); and this grabs 15,238 bytes total. BUT, I still have the quandry of the screwed up multi-bytes. I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. Approx 8% of the data. The bad bytes always seem to take the flavor of 0x2018, 0x2019, x2022, x2030, x201d. Are these maybe errors and I don't know what they enumerate to? I still can't believe some other layer isn't handling putting those bytes together all in one stream for me. Thanks Keith ----- Original Message ----- From: "Keith" To: "Bob Jacobsen" ; "RXTX Developers and Users" Sent: Saturday, March 03, 2007 11:26 AM Subject: Re: [Rxtx] is.read() only returning 3968 bytes > Bob, > > > Interesting numerical coincidence is that (max USB transfer) - (what > > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > > needed to transfer that much data. > > I was thinking along the same lines. I don't know USB well, but I do know > that those numbers were close enough to warrant investigating the > relationship between them. > > > I think what you're seeing is the internal buffering of the USB data > > stream. You'll need some form of higher-level buffering to smooth > > that out. > > Shouldn't the InputStreamReader() and BufferedReader() provide this type of > buffering? Isn't that the idea behind those? > > > All hypotheses need to be tested. In this case, a test would be to > > check for missing data. If this idea is right, you'll get _all_ the > > data, but you won't be missing characters. > > I did start looking at the data. -- I'm getting weird results. > > I tried this: > > loopzz = 0; > > for (looptwo = 0; looptwo < 100000; looptwo++) { > while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > > }} > > So I'm reading one character at a time. The good news is that loopzz is > exactly 15238 at the end of the routine, which is perfectly correct. I > picked looptwo value out of thin air. > > The weird results come in terms of the values, the data isn't correct at > least in one case. Look here: > > 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > > This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). > But the 0x89 was replaced by 0x2030. Why the heck would the returned value > be 0x2030?? Why is the returned byte completely out of range? Why the > multibyte return? > > From InputStream in the API: > > read > public abstract int read() > throws IOExceptionReads the next byte of data from the > input stream. The value byte is returned as an int in the range 0 to 255. If > no byte is available because the end of the stream has been reached, the > value -1 is returned. This method blocks until input data is available, the > end of the stream is detected, or an exception is thrown. > Value should be 0-255. > > > In my application time is really critical, reading 1 byte at a time is > probably not going to work. > > Thanks Eric & Bob for looking at this. > > Keith > From tjarvi at qbang.org Sat Mar 3 12:52:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 12:52:27 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > update: > > I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now > instead of 3968. > > This makes sense. > > 128 bytes of overhead + 3968 bytes of data = 4096 transfer size > 32 bytes of overhead + 992 bytes of data = 1024 transfer size. > > 1/4 the data = 1/4 the overhead. > > I rearranged my reading like so: > > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. > Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? > > I still can't believe some other layer isn't handling putting those bytes > together all in one stream for me. > The layer for this in Serial land is flow control. Software and hardware flow control prevent the overruns you observe. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:54:41 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:54:41 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <001a01c75dcd$c8802a70$6600a8c0@jbh757ktruws7g> Trent, Thanks for taking the time to reply. > I would expect a 20 meg application is going to have different behavior > with the OS than a smaller application with respect to the kernel memory > managment, schedualing, ... Something subtle could be causing problems. Well, at least I know the VCP drivers, the OS, etc can handle 2mbps reliably. Without hiccuping or dropping bytes. The C++ code works reliably without flow control. > The missing data is typical when not using flow control. When the OS > buffering fills, the hardware will start dropping bytes. I'm actually not getting MISSING data, I'm getting CORRUPTED data. If you look at my most recent post, I'm getting these bad bytes in place of the correct values: 0x2018, 0x2019, x2022, x2030, x201d. Why would is.read() return values not in the range of 0-255 ? Thanks. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 08:59:14 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 07:59:14 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: At 1:19 AM -0500 3/3/07, Keith wrote: >If I do a > >resultz = is.read(cbuf,0,15238); in java with RXTX > >where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > >and where resultz is an int, and cbuf is a char [] cbuf, resultz gets >EXACTLY 3968 bytes the first time called. If I call it multiple times, I get >roughly 11k total(less than what is sent), never more than the 3968 bytes >per is.read() call. > >My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 >bytes. Interesting numerical coincidence is that (max USB transfer) - (what you get) = 4096-3968 = 128 bytes is (almost) the size of the headers needed to transfer that much data. I think what you're seeing is the internal buffering of the USB data stream. You'll need some form of higher-level buffering to smooth that out. All hypotheses need to be tested. In this case, a test would be to check for missing data. If this idea is right, you'll get _all_ the data, but you won't be missing characters. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 09:26:14 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 11:26:14 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Bob, > Interesting numerical coincidence is that (max USB transfer) - (what > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > needed to transfer that much data. I was thinking along the same lines. I don't know USB well, but I do know that those numbers were close enough to warrant investigating the relationship between them. > I think what you're seeing is the internal buffering of the USB data > stream. You'll need some form of higher-level buffering to smooth > that out. Shouldn't the InputStreamReader() and BufferedReader() provide this type of buffering? Isn't that the idea behind those? > All hypotheses need to be tested. In this case, a test would be to > check for missing data. If this idea is right, you'll get _all_ the > data, but you won't be missing characters. I did start looking at the data. -- I'm getting weird results. I tried this: loopzz = 0; for (looptwo = 0; looptwo < 100000; looptwo++) { while (is.ready()) { cbuf[loopzz] = (char) is.read(); loopzz++; }} So I'm reading one character at a time. The good news is that loopzz is exactly 15238 at the end of the routine, which is perfectly correct. I picked looptwo value out of thin air. The weird results come in terms of the values, the data isn't correct at least in one case. Look here: 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). But the 0x89 was replaced by 0x2030. Why the heck would the returned value be 0x2030?? Why is the returned byte completely out of range? Why the multibyte return? >From InputStream in the API: read public abstract int read() throws IOExceptionReads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown. Value should be 0-255. In my application time is really critical, reading 1 byte at a time is probably not going to work. Thanks Eric & Bob for looking at this. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 14:44:50 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 13:44:50 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: Java's "char" type is Unicode. I think what you're seeing is a bug in the byte -> Unicode translation. 0x2018, 0x2019 are the curly open and close quotes. There used to be (and might still be) bugs in the conversion of these in a couple of libc versions. Some of the ASCII -> ISO and ISO -> ASCII routines were a little over-ambitious with respect to handling the open and close quotes, and tried to convert them to the "curly" form inappropriately. Try _not_ casting it to char. Bob At 11:26 AM -0500 3/3/07, Keith wrote: >Bob, > >> Interesting numerical coincidence is that (max USB transfer) - (what >> you get) = 4096-3968 = 128 bytes is (almost) the size of the headers >> needed to transfer that much data. > >I was thinking along the same lines. I don't know USB well, but I do know >that those numbers were close enough to warrant investigating the >relationship between them. > >> I think what you're seeing is the internal buffering of the USB data >> stream. You'll need some form of higher-level buffering to smooth >> that out. > >Shouldn't the InputStreamReader() and BufferedReader() provide this type of >buffering? Isn't that the idea behind those? > >> All hypotheses need to be tested. In this case, a test would be to >> check for missing data. If this idea is right, you'll get _all_ the >> data, but you won't be missing characters. > >I did start looking at the data. -- I'm getting weird results. > >I tried this: > >loopzz = 0; > >for (looptwo = 0; looptwo < 100000; looptwo++) { >while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > >}} > >So I'm reading one character at a time. The good news is that loopzz is >exactly 15238 at the end of the routine, which is perfectly correct. I >picked looptwo value out of thin air. > >The weird results come in terms of the values, the data isn't correct at >least in one case. Look here: > >0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > >This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). >But the 0x89 was replaced by 0x2030. Why the heck would the returned value >be 0x2030?? Why is the returned byte completely out of range? Why the >multibyte return? > >>From InputStream in the API: > >read >public abstract int read() > throws IOExceptionReads the next byte of data from the >input stream. The value byte is returned as an int in the range 0 to 255. If >no byte is available because the end of the stream has been reached, the >value -1 is returned. This method blocks until input data is available, the >end of the stream is detected, or an exception is thrown. >Value should be 0-255. > > >In my application time is really critical, reading 1 byte at a time is >probably not going to work. > >Thanks Eric & Bob for looking at this. > >Keith > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 15:10:11 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 17:10:11 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Bob said ..... > Java's "char" type is Unicode. I think what you're seeing is a bug > in the byte -> Unicode translation. Bob -- I think you hit the nail on the head. I was just coming to the same realization here. I knew that something funny was going on because the same bytes always got "corrupted." I'm pretty sure its in the InputStreamReader() functionality where the conversion junk is happening. Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. I don't know if simply changing the cast is going to work. Since the conversion is happening upstream (pun intended), I don't think my cast is doing this. Also I think the compiler forced me to use the cast. I'm still playing around, and I'll report back once I nail it down. Thanks!! Keith From tjarvi at qbang.org Sat Mar 3 15:59:46 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 15:59:46 -0700 (MST) Subject: [Rxtx] Win64 rxtx Testers? Message-ID: I have compiled win64 binaries of rxtx. Are there any users interested in testing them? If so, I'll look into putting them on the web site. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Mar 3 15:35:06 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 14:35:06 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: Because of this and similar problems, JMRI does all it's serial IO using +only+ byte values. It's a but of a pain, as Java wants to go to char and int types a little too aggressively, but it does solve the "uncontrolled conversions" problems. Bob At 5:10 PM -0500 3/3/07, Keith wrote: >Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > >Bob -- I think you hit the nail on the head. > >I was just coming to the same realization here. I knew that something funny >was going on because the same bytes always got "corrupted." > >I'm pretty sure its in the InputStreamReader() functionality where the >conversion junk is happening. > >Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > >I don't know if simply changing the cast is going to work. Since the >conversion is happening upstream (pun intended), I don't think my cast is >doing this. Also I think the compiler forced me to use the cast. -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mark at mdsh.com Sun Mar 4 11:01:33 2007 From: mark at mdsh.com (Mark Himsley) Date: Sun, 04 Mar 2007 18:01:33 +0000 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: <5C01AC72C200388815C04982@bedroom.mdsh.local> On 03 March 2007 14:38 -0500 Keith wrote: > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT > consistent. Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? It looks like you need to use DataInputStream and DataOutputStream. -- Mark Himsley From tjarvi at qbang.org Sun Mar 4 11:35:08 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 11:35:08 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" > > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > > * Line #21 - Not sure if you need a (TM) mark for > the term "Sun" > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > OK. I'm going through this today. Some groups ask if rxtx could be under their license also. I think this is a good example of why I resist multiple licenses and focus on why the current license may not be usable by them. The RXTX project is a convergence of hobby and commercial interests. I happen to do both right now. The problem with licensing is we have to stay on top of them as they change. Clearly, adding more licenses will not make this easier. I'm acting as the hobby person today. RXTX always favors the hobby people. But as we move forward, I'm going to need to bring this to lawyers at work and explain to them what is going on. Others here may have to do this also. I don't anticipate problems or unexpected changes. The goal is a consistant, comprehendable and usable license as close to what we have now as possible. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 14:52:10 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 14:52:10 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (1/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: I'm breaking this into two parts. I expect the second part will need more attention. Comments first, then the changed material below. On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > Thanks > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. OK. RXTX for consitent use. java should not be capitalized because it does not only mean Sun [TM] Java [TM]. An example of this not meaning Java is when people use RXTX with GCJ. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". There are not any contributors that are in all of RXTX yet but I did update the comment to try to reflect the current situation without making it a nightmare to maintain. I looked to see how the Linux kernel does it as a reference point. > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" The URL can be problematic. I have done so below with a time reference. GNU does not provide version information in their URLS. I picture this being a problem when the version 3 comes out. > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > This will be corrected when the copy is updated to the version linked below. ---------------- begin proposed material involved -------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. ----------------- end proposed material involved -------------------- I'll be looking at the linking issue again next. That should be all that remains other than including the 2.1 version. Let me know if you have problems with anything here. I do not want to dilute the material I post next with these housekeeping tasks. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 16:08:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 16:08:36 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: For those that are wondering what is going on here, this next bit is the meat of the changes. We agreed a long time ago to put this disclaimer in. We did a so so job. It was in rxtx 2.0, not well written, ... So some groups using rxtx that would like to ship rxtx so users don't need to download, install, go to the mail-list to find why it failed, ... Then their legal teams tell them section 5 paragraph 2 is a show stopper. That was never the intent. Now going through what remains... > and might need a (TM) suffix to make Sun happy. Added disclaimer at the ended 'all trademarks belong...' > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. OK. As you can see I was trying to adjust GNU text there for the LGPL. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. used dynamically linked terminology. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". I tried to address this more upfront with an intent statement. Let me know if you have problems with it. I also tried to make it a little more clear what was derived from the GNU solution by moving the link location closer to GNU's suggestion. > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > Thats the intent. Here is the combined fixes. Note that only the material in /*-- --*/ is being touched. The new GPL license is there but unmodified. ------------------------ begin proposed new license ------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. | | An executable that contains no derivative of any portion of RXTX, but | is designed to work with RXTX by being dynamically linked with it, | is considered a "work that uses the Library" subject to the terms and | conditions of the GNU Lesser General Public License. | | The following has been added to the RXTX License to remove | any confusion about linking to RXTX. We want to allow in part what | section 5, paragraph 2 of the LGPL does not permit in the special | case of linking over a controlled interface. The intent is to add a | Java Specification Request or standards body defined interface in the | future as another exception but one is not currently available. | | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface | | As a special exception, the copyright holders of RXTX give you | permission to link RXTX with independent modules that communicate with | RXTX solely through the Sun Microsytems CommAPI interface version 2, | regardless of the license terms of these independent modules, and to copy | and distribute the resulting combined work under terms of your choice, | provided that every copy of the combined work is accompanied by a complete | copy of the source code of RXTX (the version of RXTX used to produce the | combined work), being distributed under the terms of the GNU Lesser General | Public License plus this exception. An independent module is a | module which is not derived from or based on RXTX. | | Note that people who make modified versions of RXTX are not obligated | to grant this special exception for their modified versions; it is | their choice whether to do so. The GNU Lesser General Public License | gives permission to release a modified version without this exception; this | exception also makes it possible to release a modified version which | carries forward this exception. | | You should have received a copy of the GNU Lesser General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA | All trademarks belong to their respective owners. --------------------------------------------------------------------------*/ The original GNU Lesser General Public License Follows. GNU LESSER GENERAL PUBLIC LICENSE Version 2.1, February 1999 Copyright (C) 1991, 1999 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. [This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence the version number 2.1.] Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This license, the Lesser General Public License, applies to some specially designated software packages--typically libraries--of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below. When we speak of free software, we are referring to freedom of use, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish); that you receive source code or can get it if you want it; that you can change the software and use pieces of it in new free programs; and that you are informed that you can do these things. To protect your rights, we need to make restrictions that forbid distributors to deny you these rights or to ask you to surrender these rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library or if you modify it. For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights. We protect your rights with a two-step method: (1) we copyright the library, and (2) we offer you this license, which gives you legal permission to copy, distribute and/or modify the library. To protect each distributor, we want to make it very clear that there is no warranty for the free library. Also, if the library is modified by someone else and passed on, the recipients should know that what they have is not the original version, so that the original author's reputation will not be affected by problems that might be introduced by others. Finally, software patents pose a constant threat to the existence of any free program. We wish to make sure that a company cannot effectively restrict the users of a free program by obtaining a restrictive license from a patent holder. Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license. Most GNU software, including some libraries, is covered by the ordinary GNU General Public License. This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs. When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library. We call this license the "Lesser" General Public License because it does Less to protect the user's freedom than the ordinary General Public License. It also provides other free software developers Less of an advantage over competing non-free programs. These disadvantages are the reason we use the ordinary General Public License for many libraries. However, the Lesser license provides advantages in certain special circumstances. For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License. In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software. For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU operating system, as well as its variant, the GNU/Linux operating system. Although the Lesser General Public License is Less protective of the users' freedom, it does ensure that the user of a program that is linked with the Library has the freedom and the wherewithal to run that program using a modified version of the Library. The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, whereas the latter must be combined with the library in order to run. GNU LESSER GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License Agreement applies to any software library or other program which contains a notice placed by the copyright holder or other authorized party saying it may be distributed under the terms of this Lesser General Public License (also called "this License"). Each licensee is addressed as "you". A "library" means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables. The "Library", below, refers to any such software library or work which has been distributed under these terms. A "work based on the Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term "modification".) "Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library. Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does. 1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) The modified work must itself be a software library. b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change. c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License. d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful. (For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library. In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. 4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange. If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code. 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables. When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law. If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.) Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself. 6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications. You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things: a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.) b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. c) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution. d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place. e) Verify that the user has already received a copy of these materials or that you have already sent this user a copy. For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute. 7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things: a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above. b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work. 8. You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 9. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Library (or any work based on the Library), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Library or works based on it. 10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties with this License. 11. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply, and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 12. If the distribution and/or use of the Library is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Library under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 13. The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation. 14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Libraries If you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the ordinary General Public License). To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Also add information on how to contact you by electronic and paper mail. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the library, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the library `Frob' (a library for tweaking knobs) written by James Random Hacker. , 1 April 1990 Ty Coon, President of Vice That's all there is to it! ------------------------ end of proposed license ------------------ -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sun Mar 4 16:26:04 2007 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 04 Mar 2007 17:26:04 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <45EB558C.3010609@cox.net> Bob Jacobsen wrote: > Because of this and similar problems, JMRI does all it's serial IO > using +only+ byte values. It's a but of a pain, as Java wants to go > to char and int types a little too aggressively, but it does solve > the "uncontrolled conversions" problems. Anytime that you are reading bytes of data that is not printable, unicode text, in Java, you really need to stay away from the Readers. Use input stream only, or you will see unicode valued byte groups converted to unicode "char" values. Gregg Wonderly From joachim at buechse.de Mon Mar 5 04:23:48 2007 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 5 Mar 2007 12:23:48 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> The behaviour is exactly what you asked for in you code. is = new BufferedReader(new InputStreamReader(port.getInputStream())); Readers return Text (ie unicode chars) not bytes. You instantiate the InputStreamReader without saying which charset you want, which means "platform default". As this is on Windows, it will convert Windows characters to equivalent unicode characters. If you want to read bytes, read bytes not Text. Reading bytes is done with InputStream and BufferedInputStream. BTW: The InputStream and Reader methods that read arrays are not guarenteed to fill up the array. You always have to check what you really got, and advance your index accordingly. A typical "read up to 32k" method looks like this: InputStream is= ... // -- determine the max buffer size int len= is.available(); if (len == 0) { len= 32 * 1024; } // -- read all available data byte[] buffer= new byte[len]; int pos= 0; int read; do { read= is.read(buffer, pos, buffer.length - pos); pos= pos + read; } while (read != -1 && pos < buffer.length); Best regards, Joachim --- Joachim B?chse Phone: +41 44 500 2604 Buechse Consulting Hadlaubsteig 2 CH-8006 Z?rich On 03.03.2007, at 23:10, Keith wrote: > Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > > Bob -- I think you hit the nail on the head. > > I was just coming to the same realization here. I knew that > something funny > was going on because the same bytes always got "corrupted." > > I'm pretty sure its in the InputStreamReader() functionality where the > conversion junk is happening. > > Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > > I don't know if simply changing the cast is going to work. Since the > conversion is happening upstream (pun intended), I don't think my > cast is > doing this. Also I think the compiler forced me to use the cast. > > I'm still playing around, and I'll report back once I nail it down. > > Thanks!! > > Keith > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Mon Mar 5 07:25:46 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 05 Mar 2007 08:25:46 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> Message-ID: <45EC286A.8060608@cox.net> Joachim Buechse wrote: > BTW: The InputStream and Reader methods that read arrays are not > guarenteed to fill up the array. You always have to check what you > really got, and advance your index accordingly. A typical "read up to > 32k" method looks like this: > > InputStream is= ... > // -- determine the max buffer size > int len= is.available(); > if (len == 0) { > len= 32 * 1024; > } > // -- read all available data > byte[] buffer= new byte[len]; > int pos= 0; > int read; > do { > read= is.read(buffer, pos, buffer.length - pos); > pos= pos + read; > } while (read != -1 && pos < buffer.length); > My preferred structure is. byte arr[ len ]; int cnt; int off = 0; while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { off += cnt; } This keeps you from adding -1 to pos when the read returns -1. It also skips out when the read is 0 bytes which, is not a described EOF in InputStream java docs, but is a condition I want to be aware of. Gregg Wonderly From joachim at buechse.de Tue Mar 6 02:52:58 2007 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 6 Mar 2007 10:52:58 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <45EC286A.8060608@cox.net> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: The code I copied was from a file resource reader, it shouldn't really be applied to networking/external IO code. Mea culpa. However aborting when you get 0 from read is not always what you want either (you kind of indicated that already). Some unix java implementations will return 0 if the kernel read was aborted with EINTER, which is rarely the point where you want to abort your read - at least not without further checks. A "complete" solution always depends on the events you need to handle and the time the total read could take in reality. In some cases it's worth checking Thread.isInterrupted() in the loop, some code re-loops on 0 but only a limited number of times, some check a total timeout limit, etc... Best regards, Joachim On 05.03.2007, at 15:25, Gregg Wonderly wrote: > My preferred structure is. > > byte arr[ len ]; > int cnt; > int off = 0; > while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { > off += cnt; > } > > This keeps you from adding -1 to pos when the read returns -1. It > also skips > out when the read is 0 bytes which, is not a described EOF in > InputStream java > docs, but is a condition I want to be aware of. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Mar 6 14:47:44 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 Mar 2007 14:47:44 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: Just FYI, rxtx will usually not break out on EINTER. The code in the native library usually does something close to this: do { read(...) } while ( !done && errno==EINTR ); Obviously there is a little more involved but it will retry on EINTER if not done. On Tue, 6 Mar 2007, Joachim Buechse wrote: > The code I copied was from a file resource reader, it shouldn't > really be applied to networking/external IO code. Mea culpa. > > However aborting when you get 0 from read is not always what you want > either (you kind of indicated that already). Some unix java > implementations will return 0 if the kernel read was aborted with > EINTER, which is rarely the point where you want to abort your read - > at least not without further checks. A "complete" solution always > depends on the events you need to handle and the time the total read > could take in reality. In some cases it's worth checking > Thread.isInterrupted() in the loop, some code re-loops on 0 but only > a limited number of times, some check a total timeout limit, etc... > > Best regards, > Joachim > > On 05.03.2007, at 15:25, Gregg Wonderly wrote: >> My preferred structure is. >> >> byte arr[ len ]; >> int cnt; >> int off = 0; >> while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { >> off += cnt; >> } >> >> This keeps you from adding -1 to pos when the read returns -1. It >> also skips >> out when the read is 0 bytes which, is not a described EOF in >> InputStream java >> docs, but is a condition I want to be aware of. >> >> Gregg Wonderly >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 gjhanna at gmail.com Thu Mar 8 13:42:52 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Fri, 9 Mar 2007 09:42:52 +1300 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? Message-ID: I've just struck an issue using rxtx in a multi-threaded environment: If I have 3 threads trying to open *the same* comm-port I get a deadlock in CommPortIdentifier.open If I have just 2, it works fine - I get a PortInUseException which is nice and I can handle it. The 3 thread->deadlock thing is causing me issues. (Sample code below). This is from the java thread-dump Found one Java-level deadlock: ============================= "Thread-2": waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object ), which is held by "Thread-1" "Thread-1": waiting to lock monitor 0x0003e9cc (object 0x2450e108, a gnu.io.CommPortIdentifier), which is held by "Thread-2" Java stack information for the threads listed above: =================================================== "Thread-2": at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:329) - waiting to lock <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) "Thread-1": at java.lang.Object.wait(Native Method) - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) - locked <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) (Apart from this, rxtx is working fantastically for us). I'm thinking I'll have to implement some sort of locking mechanism that *doesn't* use java synchronization to prevent this situation. (Which doesn't sound like a good idea to me). Any ideas? Thanks, Greg Hanna ============= RXTXLockTest.java ======================================== import gnu.io.CommPort; import gnu.io.CommPortIdentifier; /** * @author Greg Hanna * Minimal code to create a deadlock with rxtx in multithreaded open */ public class RXTXLockTest { public static void main(String[] args) { try { CommPortIdentifier cpiCom1 = CommPortIdentifier.getPortIdentifier ("COM14"); OpenThread t1 = new OpenThread (" one ", cpiCom1); OpenThread t2 = new OpenThread (" two ", cpiCom1); OpenThread t3 = new OpenThread (" 003 ", cpiCom1); t1.start(); t2.start(); t3.start(); // comment this out and it runs with (expected) PortInUseException } catch (Exception e) { e.printStackTrace(); } } } class OpenThread extends Thread { String name; CommPortIdentifier cpi; CommPort cp; public OpenThread (String name, CommPortIdentifier cpi) { this.name = name; this.cpi = cpi; System.out.println (System.currentTimeMillis() + name + " thread created"); } public void run () { try { System.out.println (System.currentTimeMillis() + name + " opening"); cp = cpi.open(name, 2000); System.out.println (System.currentTimeMillis() + name + " opened - sleeping"); sleep (2000); // do the serial comms with the device. System.out.println (System.currentTimeMillis() + name + " slept - closing"); cp.close(); System.out.println (System.currentTimeMillis() + name + " closed - exiting"); } catch (Exception e) { System.out.println ("Error in thread: " + name ); e.printStackTrace(); } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070308/d9a163c5/attachment-0006.html From eu259473 at tele2.it Fri Mar 9 02:46:20 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 09 Mar 2007 10:46:20 +0100 Subject: [Rxtx] rxtx: tru64 unix make fails Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070309/3b654523/attachment-0006.html From lyon at docjava.com Fri Mar 9 03:58:32 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 Mar 2007 05:58:32 -0500 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi All, The deadlock issue is one that I have been thinking about for some time now. It seems to me that we need a resource manager that enables assignment to a known process. The one thing that seems important about serial ports is that two applications should not use the same serial port at the same time. When this happens, it throws an exception. OK. The exception is a response to a lock condition that arises from an unavailable resource. An abstract implementation (not born of native methods) might assign a serial port to an application, until the application releases it (or is forced to release it by some kill mechanism). Some resources (like a registry) can be reused. But others, like the serial port, cannot. In the case of the serial port, we would like, I think, to have the flyweight design pattern without sharing and with object assignment tracking. A means of breaking deadlock (like a leasing mechanism) seems very useful, to me. My guess is that we can serialize the state of the Parametric Singleton Pattern (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) into the Preferences of the System. Preferences.systemRoot() might help with that. When a resource is checked out, the lease time and owner are listed. A thread that does this can be killed, but applications outside of Java are problematic. There is a compelling problem here. It is not just serial ports. Sound cards, cameras, microphones, files, tape drives, etc. All are consumed resources that are assigned to an application (or user) and deprive other applications, or users, from use. What, if anything, should we do? At present we throw PortInUseExceptions. Is that it? Can we do better? OK, the port is in use. Now what? Do I have to be root to go remove lock files and kill applications? Is there a better way? Thanks! - Doug >I've just struck an issue using rxtx in a multi-threaded environment: > >If I have 3 threads trying to open *the same* >comm-port I get a deadlock in >CommPortIdentifier.open >If I have just 2, it works fine - I get a >PortInUseException which is nice and I can >handle it. > >The 3 thread->deadlock thing is causing me issues. >(Sample code below). > >This is from the java thread-dump > >Found one Java-level deadlock: >============================= >"Thread-2": > waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), > which is held by "Thread-1" >"Thread-1": > waiting to lock monitor 0x0003e9cc (object >0x2450e108, a gnu.io.CommPortIdentifier ), > which is held by "Thread-2" > >Java stack information for the threads listed above: >=================================================== >"Thread-2": > at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) > - waiting to lock <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) >"Thread-1": > at java.lang.Object.wait(Native Method) > - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) > - locked <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) > > >(Apart from this, rxtx is working fantastically for us). > >I'm thinking I'll have to implement some sort of >locking mechanism that *doesn't* use java >synchronization to prevent this situation. >(Which doesn't sound like a good idea to me). > >Any ideas? > >Thanks, > >Greg Hanna > >============= RXTXLockTest.java ======================================== > >import gnu.io.CommPort; >import gnu.io.CommPortIdentifier; > >/** > * @author Greg Hanna > * Minimal code to create a deadlock with rxtx in multithreaded open > */ >public class RXTXLockTest { > ? > ?public static void main(String[] args) { > ?try { > ?CommPortIdentifier cpiCom1 = >CommPortIdentifier.getPortIdentifier ("COM14"); > ?OpenThread t1 = new OpenThread (" one ", cpiCom1); > ?OpenThread t2 = new OpenThread (" two ", cpiCom1); > ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); > ?t1.start(); > ?t2.start(); > ?t3.start(); // comment this out >and it runs with (expected) PortInUseException > ?} catch (Exception e) { > ?e.printStackTrace(); > ?} > ?} >} > >class OpenThread extends Thread { > ?String name; > ?CommPortIdentifier cpi; > ?CommPort cp; > ?public OpenThread (String name, CommPortIdentifier cpi) { > ? this.name = name; > ?this.cpi = cpi; > ?System.out.println >(System.currentTimeMillis() + name + " thread >created"); > ?} > ?public void run () { > ?try { > ?System.out.println >(System.currentTimeMillis() + name + " opening"); > ?cp = cpi.open(name, 2000); > ?System.out.println >(System.currentTimeMillis() + name + " opened - >sleeping"); > ?sleep (2000); // do the serial comms with the device. > ?System.out.println >(System.currentTimeMillis() + name + " slept - >closing"); > ?cp.close(); > ?System.out.println >(System.currentTimeMillis() + name + " closed - >exiting"); > ?} catch (Exception e) { > System.out.println ("Error in thread: " + name ); > ?e.printStackTrace(); > ?} > ?} >} > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Mar 9 06:37:45 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 Mar 2007 06:37:45 -0700 (MST) Subject: [Rxtx] rxtx: tru64 unix make fails In-Reply-To: References: Message-ID: On Fri, 9 Mar 2007, "Giuseppe Marchese" wrote: > Sorry for delay. > ? > This is log for ./configure and make > error. > ? > thanks for attention > ? > Make: '%.java,$(TOP)/$(CLASSDEST)/%.class,$(wildcard $(SPATH)/*.java)': extra chars.? > Stop. > Hi Giuseppe You need to use GNU make with the Makefile. I suspect the tru64 make is not happy with those rules. > configure: exit 0 Looks like configure is fairly happy. From tjarvi at qbang.org Sat Mar 10 07:43:51 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 07:43:51 -0700 (MST) Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi Doug I have very little time to look into this further but what we could do is open up an rxtx 3 devel branch in which a proof of concept could be worked on. It could be the proof of concept for a JSR others including Sun could look at/work on or parts of it could be recycled in a JSR. I'm working very hard on rxtx right now but it does not show. I'm looking at win64, mac intel/ppc, usb bluetooth and usb serial dongles. Some are going to be more tested than others but they are all on the plate. I'll be pushing all the fixes upstream when they are done. So I'm very busy in 2.1 but we could open a new branch. On Fri, 9 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > The deadlock issue is one that I have been thinking about > for some time now. > It seems to me that we need a resource manager that enables assignment > to a known process. > > The one thing that seems important about serial > ports is that two applications should not use the > same serial port at the same time. When this > happens, it throws an exception. > OK. > > The exception is a response to a lock condition that > arises from an unavailable resource. > > An abstract implementation (not born of native methods) might > assign a serial port to an application, until the > application releases it (or is forced to release > it by some kill mechanism). > > Some resources (like a registry) can be reused. > But others, like the serial port, > cannot. > > In the case of the serial port, we would like, I think, to > have the flyweight design pattern > without sharing and with object assignment tracking. > A means of breaking deadlock (like a leasing > mechanism) seems very useful, to me. > > My guess is that we can serialize the state of the Parametric Singleton Pattern > (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) > into the Preferences of the System. Preferences.systemRoot() might help > with that. When a resource is checked out, the lease time and owner are > listed. A thread that does this can be killed, but applications outside of Java > are problematic. > > There is a compelling problem here. It is not just serial ports. > Sound cards, cameras, microphones, files, tape drives, etc. All are consumed > resources that are assigned to an application (or > user) and deprive other applications, > or users, from use. > > What, if anything, should we do? At present we throw PortInUseExceptions. > Is that it? > Can we do better? > OK, the port is in use. Now what? > Do I have to be root to go remove lock files and kill applications? > Is there a better way? > > Thanks! > - Doug > >> I've just struck an issue using rxtx in a multi-threaded environment: >> >> If I have 3 threads trying to open *the same* >> comm-port I get a deadlock in >> CommPortIdentifier.open >> If I have just 2, it works fine - I get a >> PortInUseException which is nice and I can >> handle it. >> >> The 3 thread->deadlock thing is causing me issues. >> (Sample code below). >> >> This is from the java thread-dump >> >> Found one Java-level deadlock: >> ============================= >> "Thread-2": >> waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), >> which is held by "Thread-1" >> "Thread-1": >> waiting to lock monitor 0x0003e9cc (object >> 0x2450e108, a gnu.io.CommPortIdentifier ), >> which is held by "Thread-2" >> >> Java stack information for the threads listed above: >> =================================================== >> "Thread-2": >> at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) >> - waiting to lock <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> "Thread-1": >> at java.lang.Object.wait(Native Method) >> - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) >> - locked <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> >> >> (Apart from this, rxtx is working fantastically for us). >> >> I'm thinking I'll have to implement some sort of >> locking mechanism that *doesn't* use java >> synchronization to prevent this situation. >> (Which doesn't sound like a good idea to me). >> >> Any ideas? >> >> Thanks, >> >> Greg Hanna >> >> ============= RXTXLockTest.java ======================================== >> >> import gnu.io.CommPort; >> import gnu.io.CommPortIdentifier; >> >> /** >> * @author Greg Hanna >> * Minimal code to create a deadlock with rxtx in multithreaded open >> */ >> public class RXTXLockTest { >> ? >> ?public static void main(String[] args) { >> ?try { >> ?CommPortIdentifier cpiCom1 = >> CommPortIdentifier.getPortIdentifier ("COM14"); >> ?OpenThread t1 = new OpenThread (" one ", cpiCom1); >> ?OpenThread t2 = new OpenThread (" two ", cpiCom1); >> ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); >> ?t1.start(); >> ?t2.start(); >> ?t3.start(); // comment this out >> and it runs with (expected) PortInUseException >> ?} catch (Exception e) { >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> class OpenThread extends Thread { >> ?String name; >> ?CommPortIdentifier cpi; >> ?CommPort cp; >> ?public OpenThread (String name, CommPortIdentifier cpi) { >> ? this.name = name; >> ?this.cpi = cpi; >> ?System.out.println >> (System.currentTimeMillis() + name + " thread >> created"); >> ?} >> ?public void run () { >> ?try { >> ?System.out.println >> (System.currentTimeMillis() + name + " opening"); >> ?cp = cpi.open(name, 2000); >> ?System.out.println >> (System.currentTimeMillis() + name + " opened - >> sleeping"); >> ?sleep (2000); // do the serial comms with the device. >> ?System.out.println >> (System.currentTimeMillis() + name + " slept - >> closing"); >> ?cp.close(); >> ?System.out.println >> (System.currentTimeMillis() + name + " closed - >> exiting"); >> ?} catch (Exception e) { >> System.out.println ("Error in thread: " + name ); >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 mm at UDel.Edu Sat Mar 10 14:48:32 2007 From: mm at UDel.Edu (Mike Markowski) Date: Sat, 10 Mar 2007 16:48:32 -0500 Subject: [Rxtx] rxtx and Sun's comm api Message-ID: <45F327B0.2060004@udel.edu> Hi all, I joined the list a few days ago and apologize for what is likely a frequently asked question, though I haven't yet found it anywhere. I learned about rxtx.org through the readme on Sun's version 2 of their comms api. They give recommendations in that readme regarding how a better comms api should be written. Is this the aim of rxtx.org? I wrote an app on my linux box using the Sun comms api (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the fact that only linux and Solaris are supported. So I'm glad to find rxtx.org and am just reading up on how make the conversion so Windows users will be able to run the program as well. At the same time I'm just curious if rxtx.org and Sun are both heading in the same direction. Thanks for any background or historical info. Feel free to point me to any www pages if my googling has just completely missed the target! Thanks again, Mike From tjarvi at qbang.org Sat Mar 10 15:35:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 15:35:25 -0700 (MST) Subject: [Rxtx] rxtx and Sun's comm api In-Reply-To: <45F327B0.2060004@udel.edu> References: <45F327B0.2060004@udel.edu> Message-ID: On Sat, 10 Mar 2007, Mike Markowski wrote: > Hi all, > > I joined the list a few days ago and apologize for what is likely a > frequently asked question, though I haven't yet found it anywhere. I > learned about rxtx.org through the readme on Sun's version 2 of their > comms api. They give recommendations in that readme regarding how a > better comms api should be written. Is this the aim of rxtx.org? > > I wrote an app on my linux box using the Sun comms api > (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the > fact that only linux and Solaris are supported. So I'm glad to find > rxtx.org and am just reading up on how make the conversion so Windows > users will be able to run the program as well. At the same time I'm > just curious if rxtx.org and Sun are both heading in the same direction. > > Thanks for any background or historical info. Feel free to point me to > any www pages if my googling has just completely missed the target! > I do not have any news (good or bad) concerning RXTX and Sun working together but perhaps others here do. The main goal of RXTX is to expose POSIX termios interfaces to java users. The future support of javax.comm is questionable. We do not have resources for everything. gnu.io (RXTX 2.1) will be supported going forward and functions the same as CommAPI 2.0. If you have control of the source code you are working with, I would not advise using CommAPI 2.0 javax.comm. We do support CommAPI 2.0 javax.comm for older applications but I do not think that will last much longer for practical reasons. The download interest in CommAPI 2.0 javax.comm support is becomming negligible on this end. There has been discussion of a JSR effort but I do not know of any status change since it was mentioned. One problem with a JSR is that even a light weight process is going to be difficult for RXTX at this time. Maybe that will change in the future but then again it may not. For now, we are just going forward 'as is' in rxtx 2.1 with package gnu.io while trying as a secondary effort to backport the changes to rxtx 2.0 for javax.comm support for users that do not have a choice. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Mar 11 07:19:40 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 11 Mar 2007 08:19:40 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: Hi All, I have been a proponent of a JSR that makes use of RXTX. I have executed the proper agreements with Sun. At this point we are in the: Early Draft Review of Draft Specifications Stage. The best thing to do is to enter the quiet period and create a specification. The question of exactly how we, as a group, want to approach this problem, remains open. Typically, we should have both a specification and a reference implementation. Thus, it would be to our best advantage to have a nice, stable, cross platform RXTX distro that adheres to the groups specification. Now, from a specification standpoint, my personal view on the matter is that we create a series of interfaces, with nice documentation (or at least javadoc). Is this a good idea? Should we have a pure interface specification for the communication API? There are several issues, in my mind, which still weigh on us. Hot-pluggable dongles, long discovery process on pop-up ports, lack of uniformity on device names, lack of uniformity on locking, a precise understanding of how the SerialPortResourceManager works (or even if we should have one). The more questions we answer in our reference implementation, the better our specification will get. RXTX is a good working prototype, but, I don't know if that is what we want to use for a specification. Here is what I have for a CommPortInterface: */ public interface CommPortInterface { /** * @return a string representation of this port. */ String toString(); /** * Gets the name of the communications port. This name should correspond to * something the user can identify, like the label on the hardware. * @return name of the port */ String getName(); /** * @return an input stream that can be used to read data from the * communications port. If the port doesn't support reading data, this * method returns null. *

* The blocking behaviour of this input stream depends on the threshold * and timeout values, as shown below for a read buffer size of n * bytes: * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ThresholdTimeoutBlocking behaviour
StateValueStateValue
disableddisabledblock until data is available
enabledm bytesdisabledblock until min(m, n) bytes are available
disabledenabledt msblock for t ms or until data is available
enabledm bytesenabledt msblock for t ms or until min(m, n) bytes are * available
* @throws java.io.IOException */ InputStream getInputStream() throws IOException; /** * @return an output stream that can be used to send data to the * communications port. If the port doesn't support sending data, this * method returns null. * @throws java.io.IOException */ OutputStream getOutputStream() throws IOException; /** * Closes this communications port. * All PortOwnershipListeners will be? * notified of this change of ownership. Further method calls on this? * object will throw IllegalStateException. Further calls on the? * associated InputStream or OutputStream will throw IOException. *

* Close does not block. Undelivered data is discarded. Blocked read and? * write operations are aborted if the underlying operating systems? * supports an IO abort mechanism. To await the delivery of undelivered? * data call OutputStream.flush() or OutputStream.close() before calling? * Port.close(). */ void close(); /** * Enables receive threshold. * When the specified threshold number of bytes are retrieved, read will * return immediately. * * @param thresh the number of bytes in the input buffer * @throws gnu.io.UnsupportedCommOperationException * if receive threshold is * not supported by the driver * @see #disableReceiveThreshold */ void enableReceiveThreshold(int thresh) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive threshold. * * @see #enableReceiveThreshold */ void disableReceiveThreshold(); /** * @return true if receive threshold is enabled. * * @see #enableReceiveThreshold */ boolean isReceiveThresholdEnabled(); /** * @return the receive threshold value. If receive threshold is diabled * or not supported, this value is meaningless. * * @see #enableReceiveThreshold */ int getReceiveThreshold(); /** * Enables receive timeout. * When the specified number of milliseconds have elapsed, read will * return immediately. * * @param rcvTimeout the number of milliseconds to block for * @throws gnu.io.UnsupportedCommOperationException * if receive timeout is * not supported by the driver * @see #disableReceiveTimeout */ void enableReceiveTimeout(int rcvTimeout) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive timeout. * * @see #enableReceiveTimeout */ void disableReceiveTimeout(); /** * @return true if receive timeout is enabled. * * @see #enableReceiveTimeout */ boolean isReceiveTimeoutEnabled(); /** * @return the receive timeout value. If receive timeout is diabled * or not supported, this value is meaningless. * * @see #enableReceiveTimeout */ int getReceiveTimeout(); /** * Enables receive framing. * The supplied byte value in the input suggests the end of the received * frame, and read returns immediately. Only the low 8 bits of the * supplied value are significant. * * @param framingByte the frame delimiter * @throws gnu.io.UnsupportedCommOperationException * if receive framing is * not supported by the driver * @see #disableReceiveFraming */ void enableReceiveFraming(int framingByte) throws UnsupportedCommOperationException; /** * Disables receive framing. * * @see #enableReceiveFraming */ void disableReceiveFraming(); /** * @return true if receive framing is enabled. * * @see #enableReceiveFraming */ boolean isReceiveFramingEnabled(); /** * @return true if receive framing byte. If receive framing is diabled * or not supported, this value is meaningless. * * @see #enableReceiveFraming */ int getReceiveFramingByte(); /** * Sets the input buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setInputBufferSize(int size); /** * @return the input buffer size. * The driver may choose not to report correct values. */ int getInputBufferSize(); /** * Sets the output buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setOutputBufferSize(int size); /** * @return the output buffer size. * The driver may choose not to report correct values. */ int getOutputBufferSize(); } What do you think of that? Note the wishy washy nature of the spec: The driver may choose to ignore this method. Is that good enough for us? Thanks! - Doug From ra85551 at gmail.com Sun Mar 11 08:44:45 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Sun, 11 Mar 2007 17:44:45 +0300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hello, world! I am writing application that communicates with modem via AT commands. My OS is Linux Kubuntu Feisty Herd, to ensure that my application will run properly under Windows XP I installed VMWare server. When I tried to send AT command and evaluate modem answer under WinXP @ VMWare server, I actually didn't receive anything. I think that VM settings are right, because I do can communicate with modem by using standard HyperTerminall as well as I can do on native Windows. So, why RXTX doesn't work under VM, but works under Linux and pure Windows XP (i tested it there) well? The send/receive method code follows. private String sendATCommand(String command, final String waitFor, final boolean isRegex, boolean isAddCRLF, long timeout) throws BeaconConnectException { final long POLL_PERIOD = 100; final int BUFFER_SIZE = 512; final byte[] buffer = new byte[BUFFER_SIZE]; final InputStream serialInput; final OutputStream serialOutput; try { serialInput = serialPort.getInputStream(); if (command != null) { serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } } catch (IOException e) { throw new MyException("serial I/O error"); } TimerTask task = new TimerTask() { int offset = 0; int bytesRead; public synchronized void run() { try { if (serialInput.available() > 0) { bytesRead = serialInput.read(buffer, offset, BUFFER_SIZE - offset); } else { return; } } catch (IOException e) { // do nothing - maybe next time we'll read something } offset += bytesRead; if (waitFor != null) { String temporary = new String(buffer, 0, offset).trim(); if (isRegex && temporary.matches(waitFor) || temporary.contains(waitFor)) { cancel(); notify(); } } } }; Timer timer = new Timer(); timer.schedule(task, POLL_PERIOD, POLL_PERIOD); synchronized (task) { try { task.wait(timeout); task.cancel(); } catch (InterruptedException e) { } } //Cut off leading and trailing CRs, LFs and zeroes String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); System.out.println(response); return response; } -- Pavel Parkhomenko From tjarvi at qbang.org Sun Mar 11 11:48:22 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:48:22 -0600 (MDT) Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: On Sun, 11 Mar 2007, Pavel Parkhomenko wrote: > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. > > private String sendATCommand(String command, final String waitFor, > final boolean isRegex, boolean isAddCRLF, long timeout) > throws BeaconConnectException > { > final long POLL_PERIOD = 100; > final int BUFFER_SIZE = 512; > final byte[] buffer = new byte[BUFFER_SIZE]; > final InputStream serialInput; > final OutputStream serialOutput; > try > { > serialInput = serialPort.getInputStream(); > if (command != null) > { > serialOutput = serialPort.getOutputStream(); > if (isAddCRLF) > { > command += "\r\n"; > } > System.out.println(command); > serialOutput.write(command.getBytes()); > } > } > catch (IOException e) > { > throw new MyException("serial I/O error"); > } > > TimerTask task = new TimerTask() > { > int offset = 0; > int bytesRead; > public synchronized void run() > { > try > { > if (serialInput.available() > 0) > { > bytesRead = serialInput.read(buffer, offset, > BUFFER_SIZE - offset); > } > else > { > return; > } > } > catch (IOException e) > { > // do nothing - maybe next time we'll read something > } > offset += bytesRead; > if (waitFor != null) > { > String temporary = new String(buffer, 0, offset).trim(); > if (isRegex && temporary.matches(waitFor) || > temporary.contains(waitFor)) > { > cancel(); > notify(); > } > } > } > }; > > Timer timer = new Timer(); > timer.schedule(task, POLL_PERIOD, POLL_PERIOD); > synchronized (task) { > try > { > task.wait(timeout); > task.cancel(); > } > catch (InterruptedException e) > { > } > } > //Cut off leading and trailing CRs, LFs and zeroes > String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); > System.out.println(response); > return response; > } > > > Hi Pavel VMWare should not be a problem. I've used it in the past - though not with a modem. Make sure nothing else is using the modem. Then look in the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an example that should work. Note that modems could care less what OS is on top. If you are trying to match new lines to the OS and sending it to the mode for AT commands, thats probably a mistake. Also it would not hurt to print out the individual bytes that you are sending to make sure they did not get mangled along the path. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 11:55:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:55:48 -0600 (MDT) Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: On Sun, 11 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > I have been a proponent of a JSR that makes > use of RXTX. I have executed the proper agreements with Sun. > > At this point we are in the: > Early Draft Review of Draft Specifications Stage. > > The best thing to do is to enter the quiet period and create > a specification. The question of exactly how we, as a group, > want to approach this problem, remains open. > > Typically, we should have both a specification and a reference > implementation. Thus, it would be to our best advantage to have > a nice, stable, cross platform RXTX distro that adheres to the > groups specification. > > Now, from a specification standpoint, my personal view on the matter is > that we create a series of interfaces, with nice documentation (or at least > javadoc). > > Is this a good idea? Should we have a pure interface specification for > the communication API? > > There are several issues, in my mind, which still weigh on us. > Hot-pluggable dongles, long discovery process on pop-up ports, > lack of uniformity on device names, lack of uniformity on locking, > a precise understanding of how the SerialPortResourceManager > works (or even if we should have one). > > The more questions we answer in our reference implementation, the > better our specification will get. RXTX is a good working prototype, > but, I don't know if that is what we want to use for a specification. > > Here is what I have for a CommPortInterface: > */ > public interface CommPortInterface { Hi Doug, I can start going through the method interfaces later this week and giving feedback. I would suggest that the JSR should not be too generic in nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel drivers that intend to look like EIA232 ports at the kernel driver level. some ideas: EIA232PortInterface TermiosInterface SerialPortInterface Something that differentiates this from thing like USB, I2C, ... which should not have to deal with legacy serial claiming to be the comm api. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 12:52:19 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 12:52:19 -0600 (MDT) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: No news is good news with these posts. I'll start the process of pinging legal a week from Monday on my end if nobody has objections to the proposal. I just want to make sure everyone has time to raise objections. Obviously, anyone can fork from a previous version if they don't like the new license. I suspect we can avoid that though. On Sun, 4 Mar 2007, Trent Jarvi wrote: > > For those that are wondering what is going on here, this > next bit is the meat of the changes. We agreed a long time > ago to put this disclaimer in. We did a so so job. It was > in rxtx 2.0, not well written, ... So some groups using > rxtx that would like to ship rxtx so users don't need to > download, install, go to the mail-list to find why it failed, > ... Then their legal teams tell them section 5 paragraph 2 > is a show stopper. > > That was never the intent. > > > Now going through what remains... > >> and might need a (TM) suffix to make Sun happy. > > Added disclaimer at the ended 'all trademarks belong...' > >> * Line #15ff - static vs. dynamic linking - you did >> not transcribe the text from the "controlled >> interface exception" when writing this text - and >> this was good so, because these terms originally >> refer to the GPL rather than the LGPL. I think though, >> that these 4 lines are the most important ones and >> should thus be really really clear. I hope that I >> meet your original intent with the following >> suggestions: >> 1.) Instead of "A program.." it would be better to >> say "An exectuable.." in order to be closer to >> the LGPL text. > > OK. As you can see I was trying to adjust GNU text there > for the LGPL. > >> 2.) It would be better to say .. "by being dynamically >> linked with it" to clearly indicate that dynamic >> linking is meant. The matter of compilation is >> already covered by the LGPL so mentioning it again >> just leads to confusion. > > used dynamically linked terminology. > >> 3.) It would be better to say .. "is considered a >> work that uses the library in contrast to section >> 5 of the LGPL, so the terms of the LGPL do not >> apply to the resulting executable". > > I tried to address this more upfront with an intent statement. > Let me know if you have problems with it. I also tried to > make it a little more clear what was derived from the GNU > solution by moving the link location closer to GNU's suggestion. > >> >> Note that LGPL section 5 says: ..."is called a >> "work that uses the Library". Such a work, in isolation, >> is not a derivative work of the Library, and therefore >> falls outside the scope of this License." >> The next paragraph of the LGPL is exactly the problematic >> one that I hope is clarified by the exception terms you >> give. >> > > Thats the intent. Here is the combined fixes. Note that only the > material in /*-- --*/ is being touched. The new GPL license is > there but unmodified. > > > ------------------------ begin proposed new license ------------------- > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Lesser General Public > | License as published by the Free Software Foundation; either > | version 2.1 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Lesser General Public License for more details. > | > | An executable that contains no derivative of any portion of RXTX, but > | is designed to work with RXTX by being dynamically linked with it, > | is considered a "work that uses the Library" subject to the terms and > | conditions of the GNU Lesser General Public License. > | > | The following has been added to the RXTX License to remove > | any confusion about linking to RXTX. We want to allow in part what > | section 5, paragraph 2 of the LGPL does not permit in the special > | case of linking over a controlled interface. The intent is to add a > | Java Specification Request or standards body defined interface in the > | future as another exception but one is not currently available. > | > | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface > | > | As a special exception, the copyright holders of RXTX give you > | permission to link RXTX with independent modules that communicate with > | RXTX solely through the Sun Microsytems CommAPI interface version 2, > | regardless of the license terms of these independent modules, and to copy > | and distribute the resulting combined work under terms of your choice, > | provided that every copy of the combined work is accompanied by a complete > | copy of the source code of RXTX (the version of RXTX used to produce the > | combined work), being distributed under the terms of the GNU Lesser General > | Public License plus this exception. An independent module is a > | module which is not derived from or based on RXTX. > | > | Note that people who make modified versions of RXTX are not obligated > | to grant this special exception for their modified versions; it is > | their choice whether to do so. The GNU Lesser General Public License > | gives permission to release a modified version without this exception; this > | exception also makes it possible to release a modified version which > | carries forward this exception. > | > | You should have received a copy of the GNU Lesser General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > | All trademarks belong to their respective owners. > --------------------------------------------------------------------------*/ > > The original GNU Lesser General Public License Follows. > > > GNU LESSER GENERAL PUBLIC LICENSE > Version 2.1, February 1999 > > Copyright (C) 1991, 1999 Free Software Foundation, Inc. > 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > Everyone is permitted to copy and distribute verbatim copies > of this license document, but changing it is not allowed. > > [This is the first released version of the Lesser GPL. It also counts > as the successor of the GNU Library Public License, version 2, hence > the version number 2.1.] > > Preamble > > The licenses for most software are designed to take away your > freedom to share and change it. By contrast, the GNU General Public > Licenses are intended to guarantee your freedom to share and change > free software--to make sure the software is free for all its users. > > This license, the Lesser General Public License, applies to some > specially designated software packages--typically libraries--of the > Free Software Foundation and other authors who decide to use it. You > can use it too, but we suggest you first think carefully about whether > this license or the ordinary General Public License is the better > strategy to use in any particular case, based on the explanations below. > > When we speak of free software, we are referring to freedom of use, > not price. Our General Public Licenses are designed to make sure that > you have the freedom to distribute copies of free software (and charge > for this service if you wish); that you receive source code or can get > it if you want it; that you can change the software and use pieces of > it in new free programs; and that you are informed that you can do > these things. > > To protect your rights, we need to make restrictions that forbid > distributors to deny you these rights or to ask you to surrender these > rights. These restrictions translate to certain responsibilities for > you if you distribute copies of the library or if you modify it. > > For example, if you distribute copies of the library, whether gratis > or for a fee, you must give the recipients all the rights that we gave > you. You must make sure that they, too, receive or can get the source > code. If you link other code with the library, you must provide > complete object files to the recipients, so that they can relink them > with the library after making changes to the library and recompiling > it. And you must show them these terms so they know their rights. > > We protect your rights with a two-step method: (1) we copyright the > library, and (2) we offer you this license, which gives you legal > permission to copy, distribute and/or modify the library. > > To protect each distributor, we want to make it very clear that > there is no warranty for the free library. Also, if the library is > modified by someone else and passed on, the recipients should know > that what they have is not the original version, so that the original > author's reputation will not be affected by problems that might be > introduced by others. > > Finally, software patents pose a constant threat to the existence of > any free program. We wish to make sure that a company cannot > effectively restrict the users of a free program by obtaining a > restrictive license from a patent holder. Therefore, we insist that > any patent license obtained for a version of the library must be > consistent with the full freedom of use specified in this license. > > Most GNU software, including some libraries, is covered by the > ordinary GNU General Public License. This license, the GNU Lesser > General Public License, applies to certain designated libraries, and > is quite different from the ordinary General Public License. We use > this license for certain libraries in order to permit linking those > libraries into non-free programs. > > When a program is linked with a library, whether statically or using > a shared library, the combination of the two is legally speaking a > combined work, a derivative of the original library. The ordinary > General Public License therefore permits such linking only if the > entire combination fits its criteria of freedom. The Lesser General > Public License permits more lax criteria for linking other code with > the library. > > We call this license the "Lesser" General Public License because it > does Less to protect the user's freedom than the ordinary General > Public License. It also provides other free software developers Less > of an advantage over competing non-free programs. These disadvantages > are the reason we use the ordinary General Public License for many > libraries. However, the Lesser license provides advantages in certain > special circumstances. > > For example, on rare occasions, there may be a special need to > encourage the widest possible use of a certain library, so that it becomes > a de-facto standard. To achieve this, non-free programs must be > allowed to use the library. A more frequent case is that a free > library does the same job as widely used non-free libraries. In this > case, there is little to gain by limiting the free library to free > software only, so we use the Lesser General Public License. > > In other cases, permission to use a particular library in non-free > programs enables a greater number of people to use a large body of > free software. For example, permission to use the GNU C Library in > non-free programs enables many more people to use the whole GNU > operating system, as well as its variant, the GNU/Linux operating > system. > > Although the Lesser General Public License is Less protective of the > users' freedom, it does ensure that the user of a program that is > linked with the Library has the freedom and the wherewithal to run > that program using a modified version of the Library. > > The precise terms and conditions for copying, distribution and > modification follow. Pay close attention to the difference between a > "work based on the library" and a "work that uses the library". The > former contains code derived from the library, whereas the latter must > be combined with the library in order to run. > > GNU LESSER GENERAL PUBLIC LICENSE > TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION > > 0. This License Agreement applies to any software library or other > program which contains a notice placed by the copyright holder or > other authorized party saying it may be distributed under the terms of > this Lesser General Public License (also called "this License"). > Each licensee is addressed as "you". > > A "library" means a collection of software functions and/or data > prepared so as to be conveniently linked with application programs > (which use some of those functions and data) to form executables. > > The "Library", below, refers to any such software library or work > which has been distributed under these terms. A "work based on the > Library" means either the Library or any derivative work under > copyright law: that is to say, a work containing the Library or a > portion of it, either verbatim or with modifications and/or translated > straightforwardly into another language. (Hereinafter, translation is > included without limitation in the term "modification".) > > "Source code" for a work means the preferred form of the work for > making modifications to it. For a library, complete source code means > all the source code for all modules it contains, plus any associated > interface definition files, plus the scripts used to control compilation > and installation of the library. > > Activities other than copying, distribution and modification are not > covered by this License; they are outside its scope. The act of > running a program using the Library is not restricted, and output from > such a program is covered only if its contents constitute a work based > on the Library (independent of the use of the Library in a tool for > writing it). Whether that is true depends on what the Library does > and what the program that uses the Library does. > > 1. You may copy and distribute verbatim copies of the Library's > complete source code as you receive it, in any medium, provided that > you conspicuously and appropriately publish on each copy an > appropriate copyright notice and disclaimer of warranty; keep intact > all the notices that refer to this License and to the absence of any > warranty; and distribute a copy of this License along with the > Library. > > You may charge a fee for the physical act of transferring a copy, > and you may at your option offer warranty protection in exchange for a > fee. > > 2. You may modify your copy or copies of the Library or any portion > of it, thus forming a work based on the Library, and copy and > distribute such modifications or work under the terms of Section 1 > above, provided that you also meet all of these conditions: > > a) The modified work must itself be a software library. > > b) You must cause the files modified to carry prominent notices > stating that you changed the files and the date of any change. > > c) You must cause the whole of the work to be licensed at no > charge to all third parties under the terms of this License. > > d) If a facility in the modified Library refers to a function or a > table of data to be supplied by an application program that uses > the facility, other than as an argument passed when the facility > is invoked, then you must make a good faith effort to ensure that, > in the event an application does not supply such function or > table, the facility still operates, and performs whatever part of > its purpose remains meaningful. > > (For example, a function in a library to compute square roots has > a purpose that is entirely well-defined independent of the > application. Therefore, Subsection 2d requires that any > application-supplied function or table used by this function must > be optional: if the application does not supply it, the square > root function must still compute square roots.) > > These requirements apply to the modified work as a whole. If > identifiable sections of that work are not derived from the Library, > and can be reasonably considered independent and separate works in > themselves, then this License, and its terms, do not apply to those > sections when you distribute them as separate works. But when you > distribute the same sections as part of a whole which is a work based > on the Library, the distribution of the whole must be on the terms of > this License, whose permissions for other licensees extend to the > entire whole, and thus to each and every part regardless of who wrote > it. > > Thus, it is not the intent of this section to claim rights or contest > your rights to work written entirely by you; rather, the intent is to > exercise the right to control the distribution of derivative or > collective works based on the Library. > > In addition, mere aggregation of another work not based on the Library > with the Library (or with a work based on the Library) on a volume of > a storage or distribution medium does not bring the other work under > the scope of this License. > > 3. You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. To do > this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version 2, > instead of to this License. (If a newer version than version 2 of the > ordinary GNU General Public License has appeared, then you can specify > that version instead if you wish.) Do not make any other change in > these notices. > > Once this change is made in a given copy, it is irreversible for > that copy, so the ordinary GNU General Public License applies to all > subsequent copies and derivative works made from that copy. > > This option is useful when you wish to copy part of the code of > the Library into a program that is not a library. > > 4. You may copy and distribute the Library (or a portion or > derivative of it, under Section 2) in object code or executable form > under the terms of Sections 1 and 2 above provided that you accompany > it with the complete corresponding machine-readable source code, which > must be distributed under the terms of Sections 1 and 2 above on a > medium customarily used for software interchange. > > If distribution of object code is made by offering access to copy > from a designated place, then offering equivalent access to copy the > source code from the same place satisfies the requirement to > distribute the source code, even though third parties are not > compelled to copy the source along with the object code. > > 5. A program that contains no derivative of any portion of the > Library, but is designed to work with the Library by being compiled or > linked with it, is called a "work that uses the Library". Such a > work, in isolation, is not a derivative work of the Library, and > therefore falls outside the scope of this License. > > However, linking a "work that uses the Library" with the Library > creates an executable that is a derivative of the Library (because it > contains portions of the Library), rather than a "work that uses the > library". The executable is therefore covered by this License. > Section 6 states terms for distribution of such executables. > > When a "work that uses the Library" uses material from a header file > that is part of the Library, the object code for the work may be a > derivative work of the Library even though the source code is not. > Whether this is true is especially significant if the work can be > linked without the Library, or if the work is itself a library. The > threshold for this to be true is not precisely defined by law. > > If such an object file uses only numerical parameters, data > structure layouts and accessors, and small macros and small inline > functions (ten lines or less in length), then the use of the object > file is unrestricted, regardless of whether it is legally a derivative > work. (Executables containing this object code plus portions of the > Library will still fall under Section 6.) > > Otherwise, if the work is a derivative of the Library, you may > distribute the object code for the work under the terms of Section 6. > Any executables containing that work also fall under Section 6, > whether or not they are linked directly with the Library itself. > > 6. As an exception to the Sections above, you may also combine or > link a "work that uses the Library" with the Library to produce a > work containing portions of the Library, and distribute that work > under terms of your choice, provided that the terms permit > modification of the work for the customer's own use and reverse > engineering for debugging such modifications. > > You must give prominent notice with each copy of the work that the > Library is used in it and that the Library and its use are covered by > this License. You must supply a copy of this License. If the work > during execution displays copyright notices, you must include the > copyright notice for the Library among them, as well as a reference > directing the user to the copy of this License. Also, you must do one > of these things: > > a) Accompany the work with the complete corresponding > machine-readable source code for the Library including whatever > changes were used in the work (which must be distributed under > Sections 1 and 2 above); and, if the work is an executable linked > with the Library, with the complete machine-readable "work that > uses the Library", as object code and/or source code, so that the > user can modify the Library and then relink to produce a modified > executable containing the modified Library. (It is understood > that the user who changes the contents of definitions files in the > Library will not necessarily be able to recompile the application > to use the modified definitions.) > > b) Use a suitable shared library mechanism for linking with the > Library. A suitable mechanism is one that (1) uses at run time a > copy of the library already present on the user's computer system, > rather than copying library functions into the executable, and (2) > will operate properly with a modified version of the library, if > the user installs one, as long as the modified version is > interface-compatible with the version that the work was made with. > > c) Accompany the work with a written offer, valid for at > least three years, to give the same user the materials > specified in Subsection 6a, above, for a charge no more > than the cost of performing this distribution. > > d) If distribution of the work is made by offering access to copy > from a designated place, offer equivalent access to copy the above > specified materials from the same place. > > e) Verify that the user has already received a copy of these > materials or that you have already sent this user a copy. > > For an executable, the required form of the "work that uses the > Library" must include any data and utility programs needed for > reproducing the executable from it. However, as a special exception, > the materials to be distributed need not include anything that is > normally distributed (in either source or binary form) with the major > components (compiler, kernel, and so on) of the operating system on > which the executable runs, unless that component itself accompanies > the executable. > > It may happen that this requirement contradicts the license > restrictions of other proprietary libraries that do not normally > accompany the operating system. Such a contradiction means you cannot > use both them and the Library together in an executable that you > distribute. > > 7. You may place library facilities that are a work based on the > Library side-by-side in a single library together with other library > facilities not covered by this License, and distribute such a combined > library, provided that the separate distribution of the work based on > the Library and of the other library facilities is otherwise > permitted, and provided that you do these two things: > > a) Accompany the combined library with a copy of the same work > based on the Library, uncombined with any other library > facilities. This must be distributed under the terms of the > Sections above. > > b) Give prominent notice with the combined library of the fact > that part of it is a work based on the Library, and explaining > where to find the accompanying uncombined form of the same work. > > 8. You may not copy, modify, sublicense, link with, or distribute > the Library except as expressly provided under this License. Any > attempt otherwise to copy, modify, sublicense, link with, or > distribute the Library is void, and will automatically terminate your > rights under this License. However, parties who have received copies, > or rights, from you under this License will not have their licenses > terminated so long as such parties remain in full compliance. > > 9. You are not required to accept this License, since you have not > signed it. However, nothing else grants you permission to modify or > distribute the Library or its derivative works. These actions are > prohibited by law if you do not accept this License. Therefore, by > modifying or distributing the Library (or any work based on the > Library), you indicate your acceptance of this License to do so, and > all its terms and conditions for copying, distributing or modifying > the Library or works based on it. > > 10. Each time you redistribute the Library (or any work based on the > Library), the recipient automatically receives a license from the > original licensor to copy, distribute, link with or modify the Library > subject to these terms and conditions. You may not impose any further > restrictions on the recipients' exercise of the rights granted herein. > You are not responsible for enforcing compliance by third parties with > this License. > > 11. If, as a consequence of a court judgment or allegation of patent > infringement or for any other reason (not limited to patent issues), > conditions are imposed on you (whether by court order, agreement or > otherwise) that contradict the conditions of this License, they do not > excuse you from the conditions of this License. If you cannot > distribute so as to satisfy simultaneously your obligations under this > License and any other pertinent obligations, then as a consequence you > may not distribute the Library at all. For example, if a patent > license would not permit royalty-free redistribution of the Library by > all those who receive copies directly or indirectly through you, then > the only way you could satisfy both it and this License would be to > refrain entirely from distribution of the Library. > > If any portion of this section is held invalid or unenforceable under any > particular circumstance, the balance of the section is intended to apply, > and the section as a whole is intended to apply in other circumstances. > > It is not the purpose of this section to induce you to infringe any > patents or other property right claims or to contest validity of any > such claims; this section has the sole purpose of protecting the > integrity of the free software distribution system which is > implemented by public license practices. Many people have made > generous contributions to the wide range of software distributed > through that system in reliance on consistent application of that > system; it is up to the author/donor to decide if he or she is willing > to distribute software through any other system and a licensee cannot > impose that choice. > > This section is intended to make thoroughly clear what is believed to > be a consequence of the rest of this License. > > 12. If the distribution and/or use of the Library is restricted in > certain countries either by patents or by copyrighted interfaces, the > original copyright holder who places the Library under this License may add > an explicit geographical distribution limitation excluding those countries, > so that distribution is permitted only in or among countries not thus > excluded. In such case, this License incorporates the limitation as if > written in the body of this License. > > 13. The Free Software Foundation may publish revised and/or new > versions of the Lesser General Public License from time to time. > Such new versions will be similar in spirit to the present version, > but may differ in detail to address new problems or concerns. > > Each version is given a distinguishing version number. If the Library > specifies a version number of this License which applies to it and > "any later version", you have the option of following the terms and > conditions either of that version or of any later version published by > the Free Software Foundation. If the Library does not specify a > license version number, you may choose any version ever published by > the Free Software Foundation. > > 14. If you wish to incorporate parts of the Library into other free > programs whose distribution conditions are incompatible with these, > write to the author to ask for permission. For software which is > copyrighted by the Free Software Foundation, write to the Free > Software Foundation; we sometimes make exceptions for this. Our > decision will be guided by the two goals of preserving the free status > of all derivatives of our free software and of promoting the sharing > and reuse of software generally. > > NO WARRANTY > > 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO > WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. > EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR > OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY > KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE > IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE > LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME > THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. > > 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN > WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY > AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU > FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR > CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE > LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING > RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A > FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF > SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH > DAMAGES. > > END OF TERMS AND CONDITIONS > > How to Apply These Terms to Your New Libraries > > If you develop a new library, and you want it to be of the greatest > possible use to the public, we recommend making it free software that > everyone can redistribute and change. You can do so by permitting > redistribution under these terms (or, alternatively, under the terms of the > ordinary General Public License). > > To apply these terms, attach the following notices to the library. It is > safest to attach them to the start of each source file to most effectively > convey the exclusion of warranty; and each file should have at least the > "copyright" line and a pointer to where the full notice is found. > > > Copyright (C) > > This library is free software; you can redistribute it and/or > modify it under the terms of the GNU Lesser General Public > License as published by the Free Software Foundation; either > version 2.1 of the License, or (at your option) any later version. > > This library is distributed in the hope that it will be useful, > but WITHOUT ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > Lesser General Public License for more details. > > You should have received a copy of the GNU Lesser General Public > License along with this library; if not, write to the Free Software > Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > > Also add information on how to contact you by electronic and paper mail. > > You should also get your employer (if you work as a programmer) or your > school, if any, to sign a "copyright disclaimer" for the library, if > necessary. Here is a sample; alter the names: > > Yoyodyne, Inc., hereby disclaims all copyright interest in the > library `Frob' (a library for tweaking knobs) written by James Random Hacker. > > , 1 April 1990 > Ty Coon, President of Vice > > That's all there is to it! > ------------------------ end of proposed license ------------------ > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From gjhanna at gmail.com Sun Mar 11 14:21:17 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Mon, 12 Mar 2007 09:21:17 +1300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hi Pavel, We are using RXTX under VMWare server in production, quite satisfactorily. We're using Red Hat Enterprise Server 4, and ... Whatever the "enterprise" VMWare product is. Regards, Greg H > Subject: [Rxtx] RXTX under VMWare server > To: rxtx at qbang.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. [ ... snip ... ] -- Pavel Parkhomenko -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070311/4cebb6f9/attachment-0006.html From gergg at cox.net Sun Mar 11 23:39:19 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 12 Mar 2007 00:39:19 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: <45F4E787.6050502@cox.net> Trent Jarvi wrote: > I can start going through the method interfaces later this week and giving > feedback. I would suggest that the JSR should not be too generic in > nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel > drivers that intend to look like EIA232 ports at the kernel driver level. > > some ideas: > > EIA232PortInterface > TermiosInterface > SerialPortInterface > > Something that differentiates this from thing like USB, I2C, ... which > should not have to deal with legacy serial claiming to be the comm api. I'm going to throw out a suggestion, which I am mostly serious about. What would happen if we took the appropriate bits of the J2ME connector API, and just used that as the new COMM API so that finally JSE and JME had a common foundation for these kinds of things? Gregg Wonderly From ra85551 at gmail.com Mon Mar 12 09:08:37 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Mon, 12 Mar 2007 18:08:37 +0300 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Should any application use the modem, HyperTerminal won't be able to talk to the modem. But it actually can send and receive AT comands, while my application cannot :-( > Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Thansk for the reference. I examined that example and found that there's no significant differences between my read/write implementation and that one, except that SimpleSnuV1 listens for serialEvent's, but not for sake of data retrieval, just for printing them out - I don't know why ;-) > Note that modems could care less what OS is on top. If you are trying to > match new lines to the OS and sending it to the mode for AT commands, > thats probably a mistake. I do send strings to serial port, not to OS, and do try to get answers back. If it is the mistake, what's the right way? > Also it would not hurt to print out the > individual bytes that you are sending to make sure they did not get > mangled along the path. Yeah, I am printing these bytes before doing write, but it means that I only see what I intend to write. How can I ensure that these bytes have gone out of the box and reached my modem? BTW, I found that my send/receive method is complex enough, so I've rewritten it. Please, see the following code and point any mistakes, because I don't know where can they remain yet. private static final int LARGE_TIMEOUT = 15000; private static final int SMALL_TIMEOUT = 500; ... private String sendATCommand(String command, String waitFor, boolean isRegex, boolean isAddCRLF) throws BeaconConnectException { byte[] buffer = new byte[512]; int offset; String result = ""; try { if (waitFor != null) { serialPort.enableReceiveTimeout(LARGE_TIMEOUT); } else { serialPort.enableReceiveTimeout(SMALL_TIMEOUT); } if (command != null) { OutputStream serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } offset = 0; InputStream serialInput = serialPort.getInputStream(); while (serialInput.available() != -1) { int bytesRead = serialInput.read(buffer, offset, buffer.length - offset); if (bytesRead == 0) { break; } offset += bytesRead; result = new String(buffer, 0, offset).trim(); if (waitFor != null) { System.out.println(result); if (isRegex && result.matches(waitFor) || result.contains(waitFor)) { break; } } } } catch (UnsupportedCommOperationException e) { throw new MyException("unsupported operation"); } catch (IOException e) { throw new MytException("serial I/O error"); } return result; } -- Pavel Parkhomenko From clayno at hotpop.com Thu Mar 15 02:47:34 2007 From: clayno at hotpop.com (Christopher Layno) Date: Thu, 15 Mar 2007 16:47:34 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi, we're using the latest release of rxtx (2.1-7r2) for our system that has two applications using the library. one application sends requests to the modem while the other simply checks the modem status. we deployed our system on a pentium machine with red hat linux 9.0 installed. now the problem arises when these two applications try to access the same modem at the same time. one of them will eventually have to throw the PortInUseException as shown below: 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException gnu.io.PortInUseException: root PID = 743 Program = java root PID = 743 Program = java root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) this was expected. what we didn't expect though was that if we repeat the scenario 5 times, always 5 times, the application would also throw a VM error: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4473CD21 Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so Current Java thread: at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) - locked <0x44cfd4c8> (a gnu.io.CommPortIdentifier) at ************ at ************ - locked <0x4476a468> (a **********) at ************ at ************ at ************ at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java :261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages( TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run( TCPTransport.java:701) at java.lang.Thread.run(Thread.java:534) note: i replaced some sensitive data with asterisks our team has looked everywhere on the internet, including your mail archives, for a solution to this problem but to no avail. i really hope you could help us out on this one. thanks in advance! best regards, chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070315/1936460a/attachment-0006.html From tjarvi at qbang.org Fri Mar 16 04:30:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 04:30:25 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: On Thu, 15 Mar 2007, Christopher Layno wrote: > hi, > > we're using the latest release of rxtx (2.1-7r2) for our system that has two > applications using the library. one application sends requests to the modem > while the other simply checks the modem status. we deployed our system on a > pentium machine with red hat linux 9.0 installed. > > now the problem arises when these two applications try to access the same > modem at the same time. one of them will eventually have to throw the > PortInUseException as shown below: > > 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException > gnu.io.PortInUseException: root PID = 743 Program = java root PID = > 743 Program = java root PID = 743 Program = ??? root PID = 743 Program > = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root > PID = 743 Program = ??? root PID = 743 Program = ??? > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > > this was expected. what we didn't expect though was that if we repeat the > scenario 5 times, always 5 times, the application would also throw a VM > error: > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x4473CD21 > Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 > Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so > > Current Java thread: > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) Hi Chris The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. The code is originally by Werner Almesberger. He gave us permission to use it in rxtx. You might look at what has changed since 1998 in his fuser application. Or you can just do like other OSs and do the following in fuserImp.c JNIEXPORT jstring JNICALL Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv *env, jobject obj, jstring arg) { return (*env)->NewStringUTF(env, "Unknown Application"); } It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. -- Trent Jarvi tjarvi at qang.org From Adrien.TOS at ingenico.com Fri Mar 16 05:11:12 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Fri, 16 Mar 2007 12:11:12 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903CBC312@frsnprexc1.usr.ingenico.loc> Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070316/972ab214/attachment-0006.html From joachim at buechse.de Fri Mar 16 05:13:24 2007 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 16 Mar 2007 12:13:24 +0100 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. From tjarvi at qbang.org Fri Mar 16 16:36:29 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 16:36:29 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Fri Mar 16 16:02:23 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 16 Mar 2007 18:02:23 -0400 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Not all platforms are Unix based. Also mixing native library usage and command-line calls is not an elegant solution, IMHO. One or the other, but not both. Andre On 16-Mar-07, at 07:13 , Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is > trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We >> only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From clayno at hotpop.com Sun Mar 18 22:17:28 2007 From: clayno at hotpop.com (Christopher Layno) Date: Mon, 19 Mar 2007 12:17:28 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi everyone, thank you so much for your replies. they were really helpful. anyway, before i sent the email, my team was already implementing a temporary solution by using joachim's suggestion. we invoked a lsof command from our java code although i share the same concern with trent and andre-john about portability issues. that's why i said it's just temporary. my superiors have yet to approve our bug fix. so my question now is this: is recompiling the rxtx source code the only way to solve this problem? because if it's the only solution, then i think my superiors would rather have a new release from the rxtx community itself that fixes this bug(?) rather than have my team recompile the source code. best regards, chris Trent Jarvi wrote: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. ... It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070318/237463b2/attachment-0006.html From tjarvi at qbang.org Mon Mar 19 16:20:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Mar 2007 16:20:52 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: Hi Chris I can compile a new version after the 21st if you do not feel comfortable doing so. Please send me an email reminder off-line then. On Mon, 19 Mar 2007, Christopher Layno wrote: > hi everyone, > > thank you so much for your replies. they were really helpful. > > anyway, before i sent the email, my team was already implementing a > temporary solution by using joachim's suggestion. > we invoked a lsof command from our java code although i share the same > concern with trent and andre-john about > portability issues. that's why i said it's just temporary. my superiors have > yet to approve our bug fix. > > so my question now is this: is recompiling the rxtx source code the only way > to solve this problem? because if it's the only > solution, then i think my superiors would rather have a new release from the > rxtx community itself that fixes this bug(?) > rather than have my team recompile the source code. > > best regards, > > chris > > Trent Jarvi wrote: > > Hi Joachim > > It would be nice to have that functionality but calling the program > introduces too many issues imho. Explaining to someone why rxtx invoked a > rogue lsof does not sound very interesting. > > On Fri, 16 Mar 2007, Joachim Buechse wrote: > > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: > > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. > > _______________________________________________ > Rxtx mailing list > Rxtx 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 Eric.Arseneau at sun.com Tue Mar 20 11:47:33 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Tue, 20 Mar 2007 10:47:33 -0700 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 Message-ID: <46001E35.9040608@sun.com> Anyone have any experience with RXTX working with JDK 6 on other platforms ? From mm at UDel.Edu Tue Mar 20 12:18:29 2007 From: mm at UDel.Edu (Mike Markowski) Date: Tue, 20 Mar 2007 14:18:29 -0400 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 In-Reply-To: <46001E35.9040608@sun.com> References: <46001E35.9040608@sun.com> Message-ID: <46002575.4000306@udel.edu> Eric Arseneau wrote: > Anyone have any experience with RXTX working with JDK 6 on other platforms ? I'm using 32 bit intel, gentoo linux, jdk6 with no problems. My applications only use a serial port, though, nothing on the parallel port. Mike From falko.guderian at gmx.de Wed Mar 21 08:17:35 2007 From: falko.guderian at gmx.de (Falko Guderian) Date: Wed, 21 Mar 2007 15:17:35 +0100 Subject: [Rxtx] RXTX binaries for SH4 Message-ID: <46013E7F.40102@gmx.de> Dear developers, I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no possiblities to compile the source code. Better, I'm not able to do this at the moment. Can you provide me with rxtxSerial.dll (SH4) in the rxtx-2.1-8-testing version? (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) The reason for the testing version is I need custom baud rates. Thanks for help. Kind regards, Falko Guderian From tjarvi at qbang.org Wed Mar 21 21:38:37 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Mar 2007 21:38:37 -0600 (MDT) Subject: [Rxtx] RXTX binaries for SH4 In-Reply-To: <46013E7F.40102@gmx.de> References: <46013E7F.40102@gmx.de> Message-ID: On Wed, 21 Mar 2007, Falko Guderian wrote: > Dear developers, > > I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no > possiblities to compile the source code. Better, I'm not able to do this > at the moment. Can you provide me with rxtxSerial.dll (SH4) in the > rxtx-2.1-8-testing version? > (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) > > The reason for the testing version is I need custom baud rates. > > Thanks for help. > Hi Falko WinCE binary format is not supported by gcc. That makes compiling limited to those familiar with the WinCE tools. I hope someone is able to provide them for you but it is not likely. WinCE has been compiled by others in the past but rxtx.org builds have never included WinCE. There is some information with the source concerning WinCE builds if you decide to do it. We can share your results too if you like. The source in the WinCE has never been updated for the custom baud rate. That would need changes from the main source I presume. If you look at the source, you will note that Michal Hobot created a mini fork in the source to handle wince but it has not been updated for 3 years. -- Trent Jarvi tjarvi at qbang.org From Adrien.TOS at ingenico.com Thu Mar 22 07:08:55 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Thu, 22 Mar 2007 14:08:55 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Hi everybody, Do you have any comments on this issue? Thanks! AT ________________________________ De : Adrien TOS Envoy? : vendredi 16 mars 2007 12:11 ? : 'rxtx at qbang.org' Cc : Adrien TOS Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070322/2306c538/attachment-0006.html From jeremy.reeve at zen.co.uk Mon Mar 19 07:36:04 2007 From: jeremy.reeve at zen.co.uk (Jeremy S. Reeve) Date: Mon, 19 Mar 2007 13:36:04 +0000 Subject: [Rxtx] rxtx failing to compile on Fedora Core 6 Message-ID: <1174311364.21865.6.camel@d9thc> When trying to compile latest source : rxtx-2.1-7r2 I get the following when running configure: ---------------- checking os.version 2.6.18-1.2200.fc5smp WARNING: configure is having a hard time determining which directory contains the file jni_md.h. Edit Makefile and fix the variable JAVANATINC to point to the correct directory. The following options are available: /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/ /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/linux/ If there are more than one option available the first was selected. WARNING: Kernel include files do not match the current kernel configure: creating ./config.status ------------------------ which seems OK checking the resultant Makefile but when attempting to build with gmake install I get the following output : ---------------------- 34 problems (34 warnings)/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/javah -classpath .:/home/jsr/rxtxsrc/rxtx-2.1-7r2:/home/jsr/rxtxsrc/rxtx-2.1-7r2/src:/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/ext/RXTXcomm.jar -d i686-pc-linux-gnu -jni `(for i in CommDriver CommPortEnumerator CommPortIdentifier CommPort CommPortOwnershipListener Configure I2C I2CPortEvent I2CPortEventListener I2CPort LPRPort NoSuchPortException ParallelPortEvent ParallelPortEventListener ParallelPort PortInUseException Raw RawPortEvent RawPortEventListener RawPort RS485 RS485PortEvent RS485PortEventListener RS485Port RXTXCommDriver RXTXPort RXTXVersion SerialPortEvent SerialPortEventListener SerialPort UnsupportedCommOperationException UnSupportedLoggerException Zystem;do \ if grep > /dev/null native.* \( /home/jsr/rxtxsrc/rxtx-2.1-7r2/./src/$i.java; then \ echo gnu.io.$i; \ fi; \ done)` i686-pc-linux-gnu/gnu_io_CommPortIdentifier.h: No such file or directory make: *** [/home/jsr/rxtxsrc/rxtx-2.1-7r2/gnu/io/CommDriver.class] Error 1 ------------------------ Any ideas or pointers? Regards, Jeremy From tjarvi at qbang.org Sat Mar 24 08:12:54 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 Mar 2007 08:12:54 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > From Adrien.TOS at ingenico.com Sat Mar 24 11:53:22 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Sat, 24 Mar 2007 18:53:22 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> I do not have the threshold setting enabled, I have explicitely disabled it with: port_.disableReceiveThreshold(); I have also run the same tests with the threshold setting enabled, but they also fail in the same way as described below. So it seems there is a problem with timeout handling on Win32? ________________________________ From: rxtx-bounces at qbang.org on behalf of Trent Jarvi Sent: Sat 3/24/2007 3:12 PM To: RXTX Developers and Users Subject: Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 8312 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20070324/f9e39c9b/attachment-0006.bin From greg.johnson at manchester.ac.uk Sun Mar 25 13:41:36 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Sun, 25 Mar 2007 21:41:36 +0200 Subject: [Rxtx] Mac intel weirdness Message-ID: Hi folks, I'm trying to get rxtx to work on my macbook pro with a USB-serial dongle on it. I am using the 2.1-8 code from the CVS (though it seems to report itself as 2.1-7: makes it difficult to prove to oneself that the changes have 'taken'! - line 4210 in SerialImp.c, line 40 in RXTXVersion.java) I am trying the 2.1-8 because of horrible lock problems in 2.1-7. However, the serialport closure code seems to be broken - it won't close because it believes the (previously opened!) port doesn't exist. Here is what I'm trying: 0. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "false" 1. Open a port Serialport serialport = (SerialPort) commportidentifier.open ("test",100); 2. Talk to a device ... 3. Close port serialport.close(); 4. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "true" - why is this? 5. Try to reopen port Serialport serialport2 = (SerialPort) commportidentifier.open("test", 100); throws PortInUseException. I've dug around a bit in the source, and it seems the SerialPort.close () should call the CommPortIdentifier.internalClosePort() (line 67 of CommPort.java). However, I crash out with the NoSuchPortException when getPortIdentifier is called. Which seems quite weird to me, seeing as it is called on this - which was create just beforehand. Does anyone know how to fix this? Cheers, greg From knute at frazmtn.com Sat Mar 24 10:32:38 2007 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 24 Mar 2007 09:32:38 -0700 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc>, Message-ID: <4604F036.17833.135298@knute.frazmtn.com> > >The behavior of timeout depends upon the setting of the threshold. Do you >have the threshold setting? > This is the same bug I reported last fall. There was a fellow that sent me an email asking if it had been fixed. I told him I didn't think so. He got somebody to write a fix for him but I have not been able to contact him again for the actual changes. The inaccurate timeout and the failure of blocking when no timeouts are set is a serious bug in my humble opinion and renders the software unusable for my applications. I'd really like to have an alternative to the Sun comm api but there just isn't one that I know of. -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Mar 26 16:17:00 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 26 Mar 2007 16:17:00 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> Message-ID: >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. From ra85551 at gmail.com Tue Mar 27 10:18:36 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Tue, 27 Mar 2007 20:18:36 +0400 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Ultimately I found a solution. At first, that wasn't actually the VMWare + WinXP + RXTX issue, that was WinXP + RXTX issue. But on pure XP it sometimes workes, sometimes not, while under VMWare I had never seen my snippet working at all. SimpleSnuV1.java would not help me, because there is only one line I missed, and SimpleSnuV1.java also doesn't contain it! It is as follows: serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_OUT | SerialPort.FLOWCONTROL_RTSCTS_IN); Thank you for your attention. -- Pavel Parkhomenko From griff at op.pl Wed Mar 28 01:28:19 2007 From: griff at op.pl (griff@op.pl) Date: Wed, 28 Mar 2007 09:28:19 +0200 Subject: [Rxtx] No blocking read on Windows. Message-ID: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/5d07d571/attachment-0006.html -------------- next part -------------- Hi, I have problem that InputStram.read() (SerialPort)?returns -1 instead blocking and waiting for data. I found that this problem was ?known in 2005 : ? >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > >> Hi Trent >> >> Thanks for the fast response. >> Here's a Q&D test program for the blocking read on windows that just >> attempts to read one byte, and prints the resulting byte. On my system it >> returns -1, where I expect that it keeps waiting for data. >> >This isn't happening on Linux so the bug is in src/termios.c.? I'll have >something this weekend to fix that. I'm using RXTX 2.1.7r2 and the problem still is here. Im using Windows XP and java 1.5 disableReciveTimeout() and disableReciveTreshhold() dont help. ? best regards ? Piotr Zielniok From Adrien.TOS at ingenico.com Wed Mar 28 01:40:46 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Wed, 28 Mar 2007 09:40:46 +0200 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903E88880@frsnprexc1.usr.ingenico.loc> Looking at the code, it seems there is no support for infinite timeout? And maybe the count++ < 20 condition is breaking out of the loop too early? The only condition to break out of the loop should either be the timeout has expired or the number of requested bytes has been received. -----Message d'origine----- De : rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] De la part de Trent Jarvi Envoy? : mardi 27 mars 2007 00:17 ? : RXTX Developers and Users Objet : Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From j.kenneth.gentle at acm.org Wed Mar 28 06:44:15 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 28 Mar 2007 08:44:15 -0400 Subject: [Rxtx] No blocking read on Windows. In-Reply-To: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> References: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> Message-ID: <200703281844.l2SIiITW028614@qbang.org> Just another "ME TOO!" - I'm seeing this problem on Windows XP, jre for windows XP/Embedded. I cranked receiveTimeout up to Integer.MAX_INT, but it doesn't seem to wait that long At 03:28 2007-03-28, you wrote: >Hi, >I have problem that InputStram.read() (SerialPort) returns -1 >instead blocking and waiting for data. I found that this problem >was known in 2005 : > > >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > > > >> Hi Trent > >> > >> Thanks for the fast response. > >> Here's a Q&D test program for the blocking read on windows that just > >> attempts to read one byte, and prints the resulting byte. On my system it > >> returns -1, where I expect that it keeps waiting for data. > >> > > >This isn't happening on Linux so the bug is in src/termios.c. I'll have > >something this weekend to fix that. > >I'm using RXTX 2.1.7r2 and the problem still is here. >Im using Windows XP and java 1.5 >disableReciveTimeout() and disableReciveTreshhold() dont help. > >best regards > >Piotr Zielniok > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From greg.johnson at manchester.ac.uk Wed Mar 28 14:43:29 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Wed, 28 Mar 2007 22:43:29 +0200 Subject: [Rxtx] Cannot close and reopen serial port Message-ID: <377F9765-7A9D-4CE9-9176-FFB63A2594F0@manchester.ac.uk> Dear all, It appears I cannot close a port properly: SerialPort serialport = portid.open("myprog",100); // do some stuff, all works fine serialport.close(); // all seems fine but... SerialPort sp2 = portid.open("myprog",100); throws PortInUseException. And when I dig into the rxtx code, I find in CommPort.java, in close(): CommPortIdentifier cp = CommPortIdentifier.getPortIdentifier(this); (line 64 or there abouts) but this throws a NoSuchPortException which is caught but ignored (line 74ish). Can anyone suggest how this could happen: a port that was valid, opened, and used, throws a NSPE when it comes to closing it? I'm pulling my (remaining) hair out over this one! Cheers, greg PS And thanks for RXTX - it's great to have! PPS (21.-7. winxp/osx both, java 1.5) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/c28852fc/attachment-0006.html From rxtx at vrijheidslaan.net Fri Mar 30 16:52:50 2007 From: rxtx at vrijheidslaan.net (Rob) Date: Fri, 30 Mar 2007 22:52:50 -0000 Subject: [Rxtx] Cvs Question Message-ID: <61896.80.126.150.87.1175295162.squirrel@webmail.provalue.nl> Hi There, Im trying to get the latest version to work on mac osx. Problem is that i can't checkout version 2.1.8. Probably my fault but can some one please give me the alternative commands for: [user at myhost]$ export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot [user at myhost]$ cvs login Thanx, Rob From ra85551 at gmail.com Thu Mar 1 03:47:06 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Thu, 1 Mar 2007 13:47:06 +0300 Subject: [Rxtx] enableReceiveTimeout() issue Message-ID: Hello, world! I found a limitation of 16300 ms for CommPort's enableReceiveTimeout() method, while in original javax.comm docs there are no any references to that. Is that a bug or feature? I actually need longer timeouts sometimees. -- Pavel Parkhomenko From lyon at docjava.com Thu Mar 1 07:54:17 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 01 Mar 2007 09:54:17 -0500 Subject: [Rxtx] parametric singleton design pattern In-Reply-To: References: <22d55aea0702081207q5e7f6785l352d498d6f5f9fb1@mail.gmail.com> <22d55aea0702100034o3bcf42f3j1d1a6257029a67b0@mail.gmail.com> Message-ID: Hi All, I have been thinking about the use of a design pattern to cache resources that are consumed by processes. Toward that end, I have arrived at a parametric singleton design pattern, which I mentioned on this list some time ago. The idea has been published at: http://www.jot.fm/issues/issue_2007_03/column2 I can't help but think that there should be an API available for dealing with the tracking of serial port usage. Perhaps it is a kind of resource manager called the: SerialPortManager basic prototypes already exist in this vain. See, for example: http://www.ce.rit.edu/research/projects/2005_fall/rt_poolsystem/doc/PoolMon/SerialPortManager.html http://www.eventhelix.com/RealtimeMantra/PatternCatalog/serial_port_design_pattern.htm And others shown by a google search on "SerialPortManager" Cheers! - Doug From Eric.Arseneau at sun.com Thu Mar 1 10:15:03 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:15:03 -0800 Subject: [Rxtx] Any known Java 6 issues with RXTX 2.1-7r2 ? Message-ID: <45E70A17.1060206@sun.com> I just did a test on a recent build of Solaris 11 x86 and it seems that I can connect to my serial device fine when Java 5 is the default, but when Java 6 is the default, no go. Any information ? From Eric.Arseneau at sun.com Thu Mar 1 10:19:58 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:19:58 -0800 Subject: [Rxtx] Mac OS X and missing data Message-ID: <45E70B3E.7040908@sun.com> We have a device which is USB based but presents itself as a serial port to a machine. On my MacBook Pro I can get excellent throughput if I get my device to send data as quickly as possible. On the desktop side, if I do an type of disk IO to log the data I get, I end up with some missing data at some point. I hooked up a USB analyzer and did confirm that all the data is sent as expected to the desktop from the device. I found a work around for this, buffer the data in memory and only write the data out when I've received it all. However, when the same code and same device is attempted on a co-workers MacBook Pro (same hardware specs), I get errors and must slow down dramatically the device side's sending of data. Any ideas/recommendations on what I can do to get rid of this error ? From what I can tell, it seems that RXTX is not able to wake up to the interrupts coming in indicating data is ready, quickly enough, is there anything I can do ? From chinkaiw at hotmail.com Fri Mar 2 00:57:43 2007 From: chinkaiw at hotmail.com (Wang Chinkai) Date: Fri, 02 Mar 2007 07:57:43 +0000 Subject: [Rxtx] dynamic detect rs232 port Message-ID: Hi all I have a question about detecting rs232 port dynamicly. I have to aceess some port and detect rs232 port at the same time. Some usb device simulates rs232 port , and I can not know what the port name it gets until it connects,so I have to detect it dynamic,but I have to access another rs232 device at the same time. I found a problem. If I use CommPortIdentifier.getPortIdentifiers() to get new port list , and the other rs232 access function will not close port correctly. So , How can I solve it . Thanks. _________________________________________________________________ ?? 2GB ???? Windows Live Mail ????????????? http://ideas.live.com/programpage.aspx?versionid=5d21c51a-b161-4314-9b0e-4911fb2b2e6d From eu259473 at tele2.it Fri Mar 2 06:16:40 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 02 Mar 2007 14:16:40 +0100 Subject: [Rxtx] rxtx on HP tru 64 unix Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070302/706c7a70/attachment-0007.html From tjarvi at qbang.org Fri Mar 2 08:39:33 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 08:39:33 -0700 (MST) Subject: [Rxtx] rxtx on HP tru 64 unix In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, "Giuseppe Marchese" wrote: > Hi > > I try to install rxtx on hp tru 64 but make fails, > There are somebody that do the same and work. > > > Sorry for may english! > > Hi Giuseppe Could you provide a log of the failure? script ./configure make # use gnu make exit The information will be in the typescript created. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 2 19:56:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 19:56:52 -0700 (MST) Subject: [Rxtx] dynamic detect rs232 port In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, Wang Chinkai wrote: > Hi all > > I have a question about detecting rs232 port dynamicly. > > I have to aceess some port and detect rs232 port at the same time. > Some usb device simulates rs232 port , and I can not know > what the port name it gets until it connects,so I have to detect it > dynamic,but I have to access > another rs232 device at the same time. > > I found a problem. Hi Wang This is a known problem. The code is braindead there. In fact there needs to be events even in a rudamentary way when you add a usb dongle. I'm burried in tasks not far from rxtx but not in rxtx. I can't get to the problem but we would accept patches if you dig into it. [I'm getting to the license question earlier too; I don't have another 10%] -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Fri Mar 2 23:19:01 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 01:19:01 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Hi, Under ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable USB -> serial converter(using virtual com port drivers), with using example code pretty much straight out of http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port opens fine, enumerations all work, etc. My application calls for a large amount of data to be transferred in a short amount of time at 2,000,000 baud. My hardware sends approximately 15,232 bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL converter work fine, and the application works using C++. In C++, I do a hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); to open the port, and a boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); to read the port. The variable buffer fills with the 15238 bytes, and returns. If I do a resultz = is.read(cbuf,0,15238); in java with RXTX where is = new BufferedReader(new InputStreamReader(port.getInputStream())); and where resultz is an int, and cbuf is a char [] cbuf, resultz gets EXACTLY 3968 bytes the first time called. If I call it multiple times, I get roughly 11k total(less than what is sent), never more than the 3968 bytes per is.read() call. My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 bytes. I've played with inputbuffersize, receive threshold, receivetimeout, and so on. The FTDI virtual com port drivers that I'm using are rock solid, and have had zero problems with them using a variety of applications, some of my own, some professionally written, etc. No flow control is used anyplace, no RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. No exceptions are being thrown. What am I doing wrong, and what I can adjust to receive the full 15k bytes in one single read? Thanks! Keith From Eric.Arseneau at sun.com Fri Mar 2 23:32:07 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Fri, 02 Mar 2007 22:32:07 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <45E91667.20501@sun.com> This is the same type of thing that is happening to me on Mac OS X and does not seem to behave the same on different machines. I posted a day or two ago on this with subject "Mac OS X and missing data". Would love to hear if there is a solution to this :) From tjarvi at qbang.org Sat Mar 3 10:54:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 10:54:17 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > Hi, > > Under > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable > USB -> serial converter(using virtual com port drivers), with using example > code pretty much straight out of > http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port > opens fine, enumerations all work, etc. > > My application calls for a large amount of data to be transferred in a short > amount of time at 2,000,000 baud. My hardware sends approximately 15,232 > bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL > converter work fine, and the application works using C++. > > In C++, I do a > > hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, > OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); > > to open the port, and a > > boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); > > to read the port. > > The variable buffer fills with the 15238 bytes, and returns. > > If I do a > > resultz = is.read(cbuf,0,15238); in java with RXTX > > where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > > and where resultz is an int, and cbuf is a char [] cbuf, resultz gets > EXACTLY 3968 bytes the first time called. If I call it multiple times, I get > roughly 11k total(less than what is sent), never more than the 3968 bytes > per is.read() call. > > My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 > bytes. > > I've played with inputbuffersize, receive threshold, receivetimeout, and so > on. The FTDI virtual com port drivers that I'm using are rock solid, and > have had zero problems with them using a variety of applications, some of my > own, some professionally written, etc. No flow control is used anyplace, no > RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. > > No exceptions are being thrown. > > What am I doing wrong, and what I can adjust to receive the full 15k bytes > in one single read? > > Thanks! > Hi Keith I would expect a 20 meg application is going to have different behavior with the OS than a smaller application with respect to the kernel memory managment, schedualing, ... Something subtle could be causing problems. With respect to the recieve timeout and threshold, if you set the timeout to zero and the threshold to the size of data you expect, read should not return until it get that data. You may try with a stand alone application that tests just that with the C/C++ API. If the read is returning with less data when tested for short reads, you have found a bug in the device driver more than likely. The USB dongle vendor would probably be interested in knowing about this. As mentioned, these devices are getting very good; almost bug free. I suspect you found a bug though if you did use the threshold and timeout properly. The missing data is typical when not using flow control. When the OS buffering fills, the hardware will start dropping bytes. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:38:52 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:38:52 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> update: I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now instead of 3968. This makes sense. 128 bytes of overhead + 3968 bytes of data = 4096 transfer size 32 bytes of overhead + 992 bytes of data = 1024 transfer size. 1/4 the data = 1/4 the overhead. I rearranged my reading like so: resultz = is.read(cbuf,0,3968); resultz = is.read(cbuf,3968,3968); resultz = is.read(cbuf,7936,3968); while (!(is.ready())); // wait for ready resultz = is.read(cbuf,11904,3334); and this grabs 15,238 bytes total. BUT, I still have the quandry of the screwed up multi-bytes. I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. Approx 8% of the data. The bad bytes always seem to take the flavor of 0x2018, 0x2019, x2022, x2030, x201d. Are these maybe errors and I don't know what they enumerate to? I still can't believe some other layer isn't handling putting those bytes together all in one stream for me. Thanks Keith ----- Original Message ----- From: "Keith" To: "Bob Jacobsen" ; "RXTX Developers and Users" Sent: Saturday, March 03, 2007 11:26 AM Subject: Re: [Rxtx] is.read() only returning 3968 bytes > Bob, > > > Interesting numerical coincidence is that (max USB transfer) - (what > > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > > needed to transfer that much data. > > I was thinking along the same lines. I don't know USB well, but I do know > that those numbers were close enough to warrant investigating the > relationship between them. > > > I think what you're seeing is the internal buffering of the USB data > > stream. You'll need some form of higher-level buffering to smooth > > that out. > > Shouldn't the InputStreamReader() and BufferedReader() provide this type of > buffering? Isn't that the idea behind those? > > > All hypotheses need to be tested. In this case, a test would be to > > check for missing data. If this idea is right, you'll get _all_ the > > data, but you won't be missing characters. > > I did start looking at the data. -- I'm getting weird results. > > I tried this: > > loopzz = 0; > > for (looptwo = 0; looptwo < 100000; looptwo++) { > while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > > }} > > So I'm reading one character at a time. The good news is that loopzz is > exactly 15238 at the end of the routine, which is perfectly correct. I > picked looptwo value out of thin air. > > The weird results come in terms of the values, the data isn't correct at > least in one case. Look here: > > 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > > This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). > But the 0x89 was replaced by 0x2030. Why the heck would the returned value > be 0x2030?? Why is the returned byte completely out of range? Why the > multibyte return? > > From InputStream in the API: > > read > public abstract int read() > throws IOExceptionReads the next byte of data from the > input stream. The value byte is returned as an int in the range 0 to 255. If > no byte is available because the end of the stream has been reached, the > value -1 is returned. This method blocks until input data is available, the > end of the stream is detected, or an exception is thrown. > Value should be 0-255. > > > In my application time is really critical, reading 1 byte at a time is > probably not going to work. > > Thanks Eric & Bob for looking at this. > > Keith > From tjarvi at qbang.org Sat Mar 3 12:52:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 12:52:27 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > update: > > I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now > instead of 3968. > > This makes sense. > > 128 bytes of overhead + 3968 bytes of data = 4096 transfer size > 32 bytes of overhead + 992 bytes of data = 1024 transfer size. > > 1/4 the data = 1/4 the overhead. > > I rearranged my reading like so: > > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. > Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? > > I still can't believe some other layer isn't handling putting those bytes > together all in one stream for me. > The layer for this in Serial land is flow control. Software and hardware flow control prevent the overruns you observe. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:54:41 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:54:41 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <001a01c75dcd$c8802a70$6600a8c0@jbh757ktruws7g> Trent, Thanks for taking the time to reply. > I would expect a 20 meg application is going to have different behavior > with the OS than a smaller application with respect to the kernel memory > managment, schedualing, ... Something subtle could be causing problems. Well, at least I know the VCP drivers, the OS, etc can handle 2mbps reliably. Without hiccuping or dropping bytes. The C++ code works reliably without flow control. > The missing data is typical when not using flow control. When the OS > buffering fills, the hardware will start dropping bytes. I'm actually not getting MISSING data, I'm getting CORRUPTED data. If you look at my most recent post, I'm getting these bad bytes in place of the correct values: 0x2018, 0x2019, x2022, x2030, x201d. Why would is.read() return values not in the range of 0-255 ? Thanks. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 08:59:14 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 07:59:14 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: At 1:19 AM -0500 3/3/07, Keith wrote: >If I do a > >resultz = is.read(cbuf,0,15238); in java with RXTX > >where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > >and where resultz is an int, and cbuf is a char [] cbuf, resultz gets >EXACTLY 3968 bytes the first time called. If I call it multiple times, I get >roughly 11k total(less than what is sent), never more than the 3968 bytes >per is.read() call. > >My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 >bytes. Interesting numerical coincidence is that (max USB transfer) - (what you get) = 4096-3968 = 128 bytes is (almost) the size of the headers needed to transfer that much data. I think what you're seeing is the internal buffering of the USB data stream. You'll need some form of higher-level buffering to smooth that out. All hypotheses need to be tested. In this case, a test would be to check for missing data. If this idea is right, you'll get _all_ the data, but you won't be missing characters. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 09:26:14 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 11:26:14 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Bob, > Interesting numerical coincidence is that (max USB transfer) - (what > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > needed to transfer that much data. I was thinking along the same lines. I don't know USB well, but I do know that those numbers were close enough to warrant investigating the relationship between them. > I think what you're seeing is the internal buffering of the USB data > stream. You'll need some form of higher-level buffering to smooth > that out. Shouldn't the InputStreamReader() and BufferedReader() provide this type of buffering? Isn't that the idea behind those? > All hypotheses need to be tested. In this case, a test would be to > check for missing data. If this idea is right, you'll get _all_ the > data, but you won't be missing characters. I did start looking at the data. -- I'm getting weird results. I tried this: loopzz = 0; for (looptwo = 0; looptwo < 100000; looptwo++) { while (is.ready()) { cbuf[loopzz] = (char) is.read(); loopzz++; }} So I'm reading one character at a time. The good news is that loopzz is exactly 15238 at the end of the routine, which is perfectly correct. I picked looptwo value out of thin air. The weird results come in terms of the values, the data isn't correct at least in one case. Look here: 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). But the 0x89 was replaced by 0x2030. Why the heck would the returned value be 0x2030?? Why is the returned byte completely out of range? Why the multibyte return? >From InputStream in the API: read public abstract int read() throws IOExceptionReads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown. Value should be 0-255. In my application time is really critical, reading 1 byte at a time is probably not going to work. Thanks Eric & Bob for looking at this. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 14:44:50 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 13:44:50 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: Java's "char" type is Unicode. I think what you're seeing is a bug in the byte -> Unicode translation. 0x2018, 0x2019 are the curly open and close quotes. There used to be (and might still be) bugs in the conversion of these in a couple of libc versions. Some of the ASCII -> ISO and ISO -> ASCII routines were a little over-ambitious with respect to handling the open and close quotes, and tried to convert them to the "curly" form inappropriately. Try _not_ casting it to char. Bob At 11:26 AM -0500 3/3/07, Keith wrote: >Bob, > >> Interesting numerical coincidence is that (max USB transfer) - (what >> you get) = 4096-3968 = 128 bytes is (almost) the size of the headers >> needed to transfer that much data. > >I was thinking along the same lines. I don't know USB well, but I do know >that those numbers were close enough to warrant investigating the >relationship between them. > >> I think what you're seeing is the internal buffering of the USB data >> stream. You'll need some form of higher-level buffering to smooth >> that out. > >Shouldn't the InputStreamReader() and BufferedReader() provide this type of >buffering? Isn't that the idea behind those? > >> All hypotheses need to be tested. In this case, a test would be to >> check for missing data. If this idea is right, you'll get _all_ the >> data, but you won't be missing characters. > >I did start looking at the data. -- I'm getting weird results. > >I tried this: > >loopzz = 0; > >for (looptwo = 0; looptwo < 100000; looptwo++) { >while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > >}} > >So I'm reading one character at a time. The good news is that loopzz is >exactly 15238 at the end of the routine, which is perfectly correct. I >picked looptwo value out of thin air. > >The weird results come in terms of the values, the data isn't correct at >least in one case. Look here: > >0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > >This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). >But the 0x89 was replaced by 0x2030. Why the heck would the returned value >be 0x2030?? Why is the returned byte completely out of range? Why the >multibyte return? > >>From InputStream in the API: > >read >public abstract int read() > throws IOExceptionReads the next byte of data from the >input stream. The value byte is returned as an int in the range 0 to 255. If >no byte is available because the end of the stream has been reached, the >value -1 is returned. This method blocks until input data is available, the >end of the stream is detected, or an exception is thrown. >Value should be 0-255. > > >In my application time is really critical, reading 1 byte at a time is >probably not going to work. > >Thanks Eric & Bob for looking at this. > >Keith > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 15:10:11 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 17:10:11 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Bob said ..... > Java's "char" type is Unicode. I think what you're seeing is a bug > in the byte -> Unicode translation. Bob -- I think you hit the nail on the head. I was just coming to the same realization here. I knew that something funny was going on because the same bytes always got "corrupted." I'm pretty sure its in the InputStreamReader() functionality where the conversion junk is happening. Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. I don't know if simply changing the cast is going to work. Since the conversion is happening upstream (pun intended), I don't think my cast is doing this. Also I think the compiler forced me to use the cast. I'm still playing around, and I'll report back once I nail it down. Thanks!! Keith From tjarvi at qbang.org Sat Mar 3 15:59:46 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 15:59:46 -0700 (MST) Subject: [Rxtx] Win64 rxtx Testers? Message-ID: I have compiled win64 binaries of rxtx. Are there any users interested in testing them? If so, I'll look into putting them on the web site. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Mar 3 15:35:06 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 14:35:06 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: Because of this and similar problems, JMRI does all it's serial IO using +only+ byte values. It's a but of a pain, as Java wants to go to char and int types a little too aggressively, but it does solve the "uncontrolled conversions" problems. Bob At 5:10 PM -0500 3/3/07, Keith wrote: >Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > >Bob -- I think you hit the nail on the head. > >I was just coming to the same realization here. I knew that something funny >was going on because the same bytes always got "corrupted." > >I'm pretty sure its in the InputStreamReader() functionality where the >conversion junk is happening. > >Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > >I don't know if simply changing the cast is going to work. Since the >conversion is happening upstream (pun intended), I don't think my cast is >doing this. Also I think the compiler forced me to use the cast. -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mark at mdsh.com Sun Mar 4 11:01:33 2007 From: mark at mdsh.com (Mark Himsley) Date: Sun, 04 Mar 2007 18:01:33 +0000 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: <5C01AC72C200388815C04982@bedroom.mdsh.local> On 03 March 2007 14:38 -0500 Keith wrote: > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT > consistent. Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? It looks like you need to use DataInputStream and DataOutputStream. -- Mark Himsley From tjarvi at qbang.org Sun Mar 4 11:35:08 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 11:35:08 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" > > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > > * Line #21 - Not sure if you need a (TM) mark for > the term "Sun" > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > OK. I'm going through this today. Some groups ask if rxtx could be under their license also. I think this is a good example of why I resist multiple licenses and focus on why the current license may not be usable by them. The RXTX project is a convergence of hobby and commercial interests. I happen to do both right now. The problem with licensing is we have to stay on top of them as they change. Clearly, adding more licenses will not make this easier. I'm acting as the hobby person today. RXTX always favors the hobby people. But as we move forward, I'm going to need to bring this to lawyers at work and explain to them what is going on. Others here may have to do this also. I don't anticipate problems or unexpected changes. The goal is a consistant, comprehendable and usable license as close to what we have now as possible. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 14:52:10 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 14:52:10 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (1/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: I'm breaking this into two parts. I expect the second part will need more attention. Comments first, then the changed material below. On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > Thanks > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. OK. RXTX for consitent use. java should not be capitalized because it does not only mean Sun [TM] Java [TM]. An example of this not meaning Java is when people use RXTX with GCJ. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". There are not any contributors that are in all of RXTX yet but I did update the comment to try to reflect the current situation without making it a nightmare to maintain. I looked to see how the Linux kernel does it as a reference point. > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" The URL can be problematic. I have done so below with a time reference. GNU does not provide version information in their URLS. I picture this being a problem when the version 3 comes out. > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > This will be corrected when the copy is updated to the version linked below. ---------------- begin proposed material involved -------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. ----------------- end proposed material involved -------------------- I'll be looking at the linking issue again next. That should be all that remains other than including the 2.1 version. Let me know if you have problems with anything here. I do not want to dilute the material I post next with these housekeeping tasks. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 16:08:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 16:08:36 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: For those that are wondering what is going on here, this next bit is the meat of the changes. We agreed a long time ago to put this disclaimer in. We did a so so job. It was in rxtx 2.0, not well written, ... So some groups using rxtx that would like to ship rxtx so users don't need to download, install, go to the mail-list to find why it failed, ... Then their legal teams tell them section 5 paragraph 2 is a show stopper. That was never the intent. Now going through what remains... > and might need a (TM) suffix to make Sun happy. Added disclaimer at the ended 'all trademarks belong...' > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. OK. As you can see I was trying to adjust GNU text there for the LGPL. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. used dynamically linked terminology. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". I tried to address this more upfront with an intent statement. Let me know if you have problems with it. I also tried to make it a little more clear what was derived from the GNU solution by moving the link location closer to GNU's suggestion. > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > Thats the intent. Here is the combined fixes. Note that only the material in /*-- --*/ is being touched. The new GPL license is there but unmodified. ------------------------ begin proposed new license ------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. | | An executable that contains no derivative of any portion of RXTX, but | is designed to work with RXTX by being dynamically linked with it, | is considered a "work that uses the Library" subject to the terms and | conditions of the GNU Lesser General Public License. | | The following has been added to the RXTX License to remove | any confusion about linking to RXTX. We want to allow in part what | section 5, paragraph 2 of the LGPL does not permit in the special | case of linking over a controlled interface. The intent is to add a | Java Specification Request or standards body defined interface in the | future as another exception but one is not currently available. | | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface | | As a special exception, the copyright holders of RXTX give you | permission to link RXTX with independent modules that communicate with | RXTX solely through the Sun Microsytems CommAPI interface version 2, | regardless of the license terms of these independent modules, and to copy | and distribute the resulting combined work under terms of your choice, | provided that every copy of the combined work is accompanied by a complete | copy of the source code of RXTX (the version of RXTX used to produce the | combined work), being distributed under the terms of the GNU Lesser General | Public License plus this exception. An independent module is a | module which is not derived from or based on RXTX. | | Note that people who make modified versions of RXTX are not obligated | to grant this special exception for their modified versions; it is | their choice whether to do so. The GNU Lesser General Public License | gives permission to release a modified version without this exception; this | exception also makes it possible to release a modified version which | carries forward this exception. | | You should have received a copy of the GNU Lesser General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA | All trademarks belong to their respective owners. --------------------------------------------------------------------------*/ The original GNU Lesser General Public License Follows. GNU LESSER GENERAL PUBLIC LICENSE Version 2.1, February 1999 Copyright (C) 1991, 1999 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. [This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence the version number 2.1.] Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This license, the Lesser General Public License, applies to some specially designated software packages--typically libraries--of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below. When we speak of free software, we are referring to freedom of use, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish); that you receive source code or can get it if you want it; that you can change the software and use pieces of it in new free programs; and that you are informed that you can do these things. To protect your rights, we need to make restrictions that forbid distributors to deny you these rights or to ask you to surrender these rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library or if you modify it. For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights. We protect your rights with a two-step method: (1) we copyright the library, and (2) we offer you this license, which gives you legal permission to copy, distribute and/or modify the library. To protect each distributor, we want to make it very clear that there is no warranty for the free library. Also, if the library is modified by someone else and passed on, the recipients should know that what they have is not the original version, so that the original author's reputation will not be affected by problems that might be introduced by others. Finally, software patents pose a constant threat to the existence of any free program. We wish to make sure that a company cannot effectively restrict the users of a free program by obtaining a restrictive license from a patent holder. Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license. Most GNU software, including some libraries, is covered by the ordinary GNU General Public License. This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs. When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library. We call this license the "Lesser" General Public License because it does Less to protect the user's freedom than the ordinary General Public License. It also provides other free software developers Less of an advantage over competing non-free programs. These disadvantages are the reason we use the ordinary General Public License for many libraries. However, the Lesser license provides advantages in certain special circumstances. For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License. In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software. For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU operating system, as well as its variant, the GNU/Linux operating system. Although the Lesser General Public License is Less protective of the users' freedom, it does ensure that the user of a program that is linked with the Library has the freedom and the wherewithal to run that program using a modified version of the Library. The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, whereas the latter must be combined with the library in order to run. GNU LESSER GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License Agreement applies to any software library or other program which contains a notice placed by the copyright holder or other authorized party saying it may be distributed under the terms of this Lesser General Public License (also called "this License"). Each licensee is addressed as "you". A "library" means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables. The "Library", below, refers to any such software library or work which has been distributed under these terms. A "work based on the Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term "modification".) "Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library. Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does. 1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) The modified work must itself be a software library. b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change. c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License. d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful. (For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library. In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. 4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange. If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code. 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables. When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law. If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.) Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself. 6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications. You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things: a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.) b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. c) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution. d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place. e) Verify that the user has already received a copy of these materials or that you have already sent this user a copy. For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute. 7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things: a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above. b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work. 8. You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 9. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Library (or any work based on the Library), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Library or works based on it. 10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties with this License. 11. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply, and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 12. If the distribution and/or use of the Library is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Library under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 13. The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation. 14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Libraries If you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the ordinary General Public License). To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Also add information on how to contact you by electronic and paper mail. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the library, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the library `Frob' (a library for tweaking knobs) written by James Random Hacker. , 1 April 1990 Ty Coon, President of Vice That's all there is to it! ------------------------ end of proposed license ------------------ -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sun Mar 4 16:26:04 2007 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 04 Mar 2007 17:26:04 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <45EB558C.3010609@cox.net> Bob Jacobsen wrote: > Because of this and similar problems, JMRI does all it's serial IO > using +only+ byte values. It's a but of a pain, as Java wants to go > to char and int types a little too aggressively, but it does solve > the "uncontrolled conversions" problems. Anytime that you are reading bytes of data that is not printable, unicode text, in Java, you really need to stay away from the Readers. Use input stream only, or you will see unicode valued byte groups converted to unicode "char" values. Gregg Wonderly From joachim at buechse.de Mon Mar 5 04:23:48 2007 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 5 Mar 2007 12:23:48 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> The behaviour is exactly what you asked for in you code. is = new BufferedReader(new InputStreamReader(port.getInputStream())); Readers return Text (ie unicode chars) not bytes. You instantiate the InputStreamReader without saying which charset you want, which means "platform default". As this is on Windows, it will convert Windows characters to equivalent unicode characters. If you want to read bytes, read bytes not Text. Reading bytes is done with InputStream and BufferedInputStream. BTW: The InputStream and Reader methods that read arrays are not guarenteed to fill up the array. You always have to check what you really got, and advance your index accordingly. A typical "read up to 32k" method looks like this: InputStream is= ... // -- determine the max buffer size int len= is.available(); if (len == 0) { len= 32 * 1024; } // -- read all available data byte[] buffer= new byte[len]; int pos= 0; int read; do { read= is.read(buffer, pos, buffer.length - pos); pos= pos + read; } while (read != -1 && pos < buffer.length); Best regards, Joachim --- Joachim B?chse Phone: +41 44 500 2604 Buechse Consulting Hadlaubsteig 2 CH-8006 Z?rich On 03.03.2007, at 23:10, Keith wrote: > Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > > Bob -- I think you hit the nail on the head. > > I was just coming to the same realization here. I knew that > something funny > was going on because the same bytes always got "corrupted." > > I'm pretty sure its in the InputStreamReader() functionality where the > conversion junk is happening. > > Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > > I don't know if simply changing the cast is going to work. Since the > conversion is happening upstream (pun intended), I don't think my > cast is > doing this. Also I think the compiler forced me to use the cast. > > I'm still playing around, and I'll report back once I nail it down. > > Thanks!! > > Keith > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Mon Mar 5 07:25:46 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 05 Mar 2007 08:25:46 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> Message-ID: <45EC286A.8060608@cox.net> Joachim Buechse wrote: > BTW: The InputStream and Reader methods that read arrays are not > guarenteed to fill up the array. You always have to check what you > really got, and advance your index accordingly. A typical "read up to > 32k" method looks like this: > > InputStream is= ... > // -- determine the max buffer size > int len= is.available(); > if (len == 0) { > len= 32 * 1024; > } > // -- read all available data > byte[] buffer= new byte[len]; > int pos= 0; > int read; > do { > read= is.read(buffer, pos, buffer.length - pos); > pos= pos + read; > } while (read != -1 && pos < buffer.length); > My preferred structure is. byte arr[ len ]; int cnt; int off = 0; while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { off += cnt; } This keeps you from adding -1 to pos when the read returns -1. It also skips out when the read is 0 bytes which, is not a described EOF in InputStream java docs, but is a condition I want to be aware of. Gregg Wonderly From joachim at buechse.de Tue Mar 6 02:52:58 2007 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 6 Mar 2007 10:52:58 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <45EC286A.8060608@cox.net> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: The code I copied was from a file resource reader, it shouldn't really be applied to networking/external IO code. Mea culpa. However aborting when you get 0 from read is not always what you want either (you kind of indicated that already). Some unix java implementations will return 0 if the kernel read was aborted with EINTER, which is rarely the point where you want to abort your read - at least not without further checks. A "complete" solution always depends on the events you need to handle and the time the total read could take in reality. In some cases it's worth checking Thread.isInterrupted() in the loop, some code re-loops on 0 but only a limited number of times, some check a total timeout limit, etc... Best regards, Joachim On 05.03.2007, at 15:25, Gregg Wonderly wrote: > My preferred structure is. > > byte arr[ len ]; > int cnt; > int off = 0; > while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { > off += cnt; > } > > This keeps you from adding -1 to pos when the read returns -1. It > also skips > out when the read is 0 bytes which, is not a described EOF in > InputStream java > docs, but is a condition I want to be aware of. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Mar 6 14:47:44 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 Mar 2007 14:47:44 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: Just FYI, rxtx will usually not break out on EINTER. The code in the native library usually does something close to this: do { read(...) } while ( !done && errno==EINTR ); Obviously there is a little more involved but it will retry on EINTER if not done. On Tue, 6 Mar 2007, Joachim Buechse wrote: > The code I copied was from a file resource reader, it shouldn't > really be applied to networking/external IO code. Mea culpa. > > However aborting when you get 0 from read is not always what you want > either (you kind of indicated that already). Some unix java > implementations will return 0 if the kernel read was aborted with > EINTER, which is rarely the point where you want to abort your read - > at least not without further checks. A "complete" solution always > depends on the events you need to handle and the time the total read > could take in reality. In some cases it's worth checking > Thread.isInterrupted() in the loop, some code re-loops on 0 but only > a limited number of times, some check a total timeout limit, etc... > > Best regards, > Joachim > > On 05.03.2007, at 15:25, Gregg Wonderly wrote: >> My preferred structure is. >> >> byte arr[ len ]; >> int cnt; >> int off = 0; >> while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { >> off += cnt; >> } >> >> This keeps you from adding -1 to pos when the read returns -1. It >> also skips >> out when the read is 0 bytes which, is not a described EOF in >> InputStream java >> docs, but is a condition I want to be aware of. >> >> Gregg Wonderly >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 gjhanna at gmail.com Thu Mar 8 13:42:52 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Fri, 9 Mar 2007 09:42:52 +1300 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? Message-ID: I've just struck an issue using rxtx in a multi-threaded environment: If I have 3 threads trying to open *the same* comm-port I get a deadlock in CommPortIdentifier.open If I have just 2, it works fine - I get a PortInUseException which is nice and I can handle it. The 3 thread->deadlock thing is causing me issues. (Sample code below). This is from the java thread-dump Found one Java-level deadlock: ============================= "Thread-2": waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object ), which is held by "Thread-1" "Thread-1": waiting to lock monitor 0x0003e9cc (object 0x2450e108, a gnu.io.CommPortIdentifier), which is held by "Thread-2" Java stack information for the threads listed above: =================================================== "Thread-2": at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:329) - waiting to lock <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) "Thread-1": at java.lang.Object.wait(Native Method) - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) - locked <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) (Apart from this, rxtx is working fantastically for us). I'm thinking I'll have to implement some sort of locking mechanism that *doesn't* use java synchronization to prevent this situation. (Which doesn't sound like a good idea to me). Any ideas? Thanks, Greg Hanna ============= RXTXLockTest.java ======================================== import gnu.io.CommPort; import gnu.io.CommPortIdentifier; /** * @author Greg Hanna * Minimal code to create a deadlock with rxtx in multithreaded open */ public class RXTXLockTest { public static void main(String[] args) { try { CommPortIdentifier cpiCom1 = CommPortIdentifier.getPortIdentifier ("COM14"); OpenThread t1 = new OpenThread (" one ", cpiCom1); OpenThread t2 = new OpenThread (" two ", cpiCom1); OpenThread t3 = new OpenThread (" 003 ", cpiCom1); t1.start(); t2.start(); t3.start(); // comment this out and it runs with (expected) PortInUseException } catch (Exception e) { e.printStackTrace(); } } } class OpenThread extends Thread { String name; CommPortIdentifier cpi; CommPort cp; public OpenThread (String name, CommPortIdentifier cpi) { this.name = name; this.cpi = cpi; System.out.println (System.currentTimeMillis() + name + " thread created"); } public void run () { try { System.out.println (System.currentTimeMillis() + name + " opening"); cp = cpi.open(name, 2000); System.out.println (System.currentTimeMillis() + name + " opened - sleeping"); sleep (2000); // do the serial comms with the device. System.out.println (System.currentTimeMillis() + name + " slept - closing"); cp.close(); System.out.println (System.currentTimeMillis() + name + " closed - exiting"); } catch (Exception e) { System.out.println ("Error in thread: " + name ); e.printStackTrace(); } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070308/d9a163c5/attachment-0007.html From eu259473 at tele2.it Fri Mar 9 02:46:20 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 09 Mar 2007 10:46:20 +0100 Subject: [Rxtx] rxtx: tru64 unix make fails Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070309/3b654523/attachment-0007.html From lyon at docjava.com Fri Mar 9 03:58:32 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 Mar 2007 05:58:32 -0500 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi All, The deadlock issue is one that I have been thinking about for some time now. It seems to me that we need a resource manager that enables assignment to a known process. The one thing that seems important about serial ports is that two applications should not use the same serial port at the same time. When this happens, it throws an exception. OK. The exception is a response to a lock condition that arises from an unavailable resource. An abstract implementation (not born of native methods) might assign a serial port to an application, until the application releases it (or is forced to release it by some kill mechanism). Some resources (like a registry) can be reused. But others, like the serial port, cannot. In the case of the serial port, we would like, I think, to have the flyweight design pattern without sharing and with object assignment tracking. A means of breaking deadlock (like a leasing mechanism) seems very useful, to me. My guess is that we can serialize the state of the Parametric Singleton Pattern (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) into the Preferences of the System. Preferences.systemRoot() might help with that. When a resource is checked out, the lease time and owner are listed. A thread that does this can be killed, but applications outside of Java are problematic. There is a compelling problem here. It is not just serial ports. Sound cards, cameras, microphones, files, tape drives, etc. All are consumed resources that are assigned to an application (or user) and deprive other applications, or users, from use. What, if anything, should we do? At present we throw PortInUseExceptions. Is that it? Can we do better? OK, the port is in use. Now what? Do I have to be root to go remove lock files and kill applications? Is there a better way? Thanks! - Doug >I've just struck an issue using rxtx in a multi-threaded environment: > >If I have 3 threads trying to open *the same* >comm-port I get a deadlock in >CommPortIdentifier.open >If I have just 2, it works fine - I get a >PortInUseException which is nice and I can >handle it. > >The 3 thread->deadlock thing is causing me issues. >(Sample code below). > >This is from the java thread-dump > >Found one Java-level deadlock: >============================= >"Thread-2": > waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), > which is held by "Thread-1" >"Thread-1": > waiting to lock monitor 0x0003e9cc (object >0x2450e108, a gnu.io.CommPortIdentifier ), > which is held by "Thread-2" > >Java stack information for the threads listed above: >=================================================== >"Thread-2": > at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) > - waiting to lock <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) >"Thread-1": > at java.lang.Object.wait(Native Method) > - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) > - locked <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) > > >(Apart from this, rxtx is working fantastically for us). > >I'm thinking I'll have to implement some sort of >locking mechanism that *doesn't* use java >synchronization to prevent this situation. >(Which doesn't sound like a good idea to me). > >Any ideas? > >Thanks, > >Greg Hanna > >============= RXTXLockTest.java ======================================== > >import gnu.io.CommPort; >import gnu.io.CommPortIdentifier; > >/** > * @author Greg Hanna > * Minimal code to create a deadlock with rxtx in multithreaded open > */ >public class RXTXLockTest { > ? > ?public static void main(String[] args) { > ?try { > ?CommPortIdentifier cpiCom1 = >CommPortIdentifier.getPortIdentifier ("COM14"); > ?OpenThread t1 = new OpenThread (" one ", cpiCom1); > ?OpenThread t2 = new OpenThread (" two ", cpiCom1); > ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); > ?t1.start(); > ?t2.start(); > ?t3.start(); // comment this out >and it runs with (expected) PortInUseException > ?} catch (Exception e) { > ?e.printStackTrace(); > ?} > ?} >} > >class OpenThread extends Thread { > ?String name; > ?CommPortIdentifier cpi; > ?CommPort cp; > ?public OpenThread (String name, CommPortIdentifier cpi) { > ? this.name = name; > ?this.cpi = cpi; > ?System.out.println >(System.currentTimeMillis() + name + " thread >created"); > ?} > ?public void run () { > ?try { > ?System.out.println >(System.currentTimeMillis() + name + " opening"); > ?cp = cpi.open(name, 2000); > ?System.out.println >(System.currentTimeMillis() + name + " opened - >sleeping"); > ?sleep (2000); // do the serial comms with the device. > ?System.out.println >(System.currentTimeMillis() + name + " slept - >closing"); > ?cp.close(); > ?System.out.println >(System.currentTimeMillis() + name + " closed - >exiting"); > ?} catch (Exception e) { > System.out.println ("Error in thread: " + name ); > ?e.printStackTrace(); > ?} > ?} >} > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Mar 9 06:37:45 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 Mar 2007 06:37:45 -0700 (MST) Subject: [Rxtx] rxtx: tru64 unix make fails In-Reply-To: References: Message-ID: On Fri, 9 Mar 2007, "Giuseppe Marchese" wrote: > Sorry for delay. > ? > This is log for ./configure and make > error. > ? > thanks for attention > ? > Make: '%.java,$(TOP)/$(CLASSDEST)/%.class,$(wildcard $(SPATH)/*.java)': extra chars.? > Stop. > Hi Giuseppe You need to use GNU make with the Makefile. I suspect the tru64 make is not happy with those rules. > configure: exit 0 Looks like configure is fairly happy. From tjarvi at qbang.org Sat Mar 10 07:43:51 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 07:43:51 -0700 (MST) Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi Doug I have very little time to look into this further but what we could do is open up an rxtx 3 devel branch in which a proof of concept could be worked on. It could be the proof of concept for a JSR others including Sun could look at/work on or parts of it could be recycled in a JSR. I'm working very hard on rxtx right now but it does not show. I'm looking at win64, mac intel/ppc, usb bluetooth and usb serial dongles. Some are going to be more tested than others but they are all on the plate. I'll be pushing all the fixes upstream when they are done. So I'm very busy in 2.1 but we could open a new branch. On Fri, 9 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > The deadlock issue is one that I have been thinking about > for some time now. > It seems to me that we need a resource manager that enables assignment > to a known process. > > The one thing that seems important about serial > ports is that two applications should not use the > same serial port at the same time. When this > happens, it throws an exception. > OK. > > The exception is a response to a lock condition that > arises from an unavailable resource. > > An abstract implementation (not born of native methods) might > assign a serial port to an application, until the > application releases it (or is forced to release > it by some kill mechanism). > > Some resources (like a registry) can be reused. > But others, like the serial port, > cannot. > > In the case of the serial port, we would like, I think, to > have the flyweight design pattern > without sharing and with object assignment tracking. > A means of breaking deadlock (like a leasing > mechanism) seems very useful, to me. > > My guess is that we can serialize the state of the Parametric Singleton Pattern > (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) > into the Preferences of the System. Preferences.systemRoot() might help > with that. When a resource is checked out, the lease time and owner are > listed. A thread that does this can be killed, but applications outside of Java > are problematic. > > There is a compelling problem here. It is not just serial ports. > Sound cards, cameras, microphones, files, tape drives, etc. All are consumed > resources that are assigned to an application (or > user) and deprive other applications, > or users, from use. > > What, if anything, should we do? At present we throw PortInUseExceptions. > Is that it? > Can we do better? > OK, the port is in use. Now what? > Do I have to be root to go remove lock files and kill applications? > Is there a better way? > > Thanks! > - Doug > >> I've just struck an issue using rxtx in a multi-threaded environment: >> >> If I have 3 threads trying to open *the same* >> comm-port I get a deadlock in >> CommPortIdentifier.open >> If I have just 2, it works fine - I get a >> PortInUseException which is nice and I can >> handle it. >> >> The 3 thread->deadlock thing is causing me issues. >> (Sample code below). >> >> This is from the java thread-dump >> >> Found one Java-level deadlock: >> ============================= >> "Thread-2": >> waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), >> which is held by "Thread-1" >> "Thread-1": >> waiting to lock monitor 0x0003e9cc (object >> 0x2450e108, a gnu.io.CommPortIdentifier ), >> which is held by "Thread-2" >> >> Java stack information for the threads listed above: >> =================================================== >> "Thread-2": >> at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) >> - waiting to lock <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> "Thread-1": >> at java.lang.Object.wait(Native Method) >> - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) >> - locked <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> >> >> (Apart from this, rxtx is working fantastically for us). >> >> I'm thinking I'll have to implement some sort of >> locking mechanism that *doesn't* use java >> synchronization to prevent this situation. >> (Which doesn't sound like a good idea to me). >> >> Any ideas? >> >> Thanks, >> >> Greg Hanna >> >> ============= RXTXLockTest.java ======================================== >> >> import gnu.io.CommPort; >> import gnu.io.CommPortIdentifier; >> >> /** >> * @author Greg Hanna >> * Minimal code to create a deadlock with rxtx in multithreaded open >> */ >> public class RXTXLockTest { >> ? >> ?public static void main(String[] args) { >> ?try { >> ?CommPortIdentifier cpiCom1 = >> CommPortIdentifier.getPortIdentifier ("COM14"); >> ?OpenThread t1 = new OpenThread (" one ", cpiCom1); >> ?OpenThread t2 = new OpenThread (" two ", cpiCom1); >> ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); >> ?t1.start(); >> ?t2.start(); >> ?t3.start(); // comment this out >> and it runs with (expected) PortInUseException >> ?} catch (Exception e) { >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> class OpenThread extends Thread { >> ?String name; >> ?CommPortIdentifier cpi; >> ?CommPort cp; >> ?public OpenThread (String name, CommPortIdentifier cpi) { >> ? this.name = name; >> ?this.cpi = cpi; >> ?System.out.println >> (System.currentTimeMillis() + name + " thread >> created"); >> ?} >> ?public void run () { >> ?try { >> ?System.out.println >> (System.currentTimeMillis() + name + " opening"); >> ?cp = cpi.open(name, 2000); >> ?System.out.println >> (System.currentTimeMillis() + name + " opened - >> sleeping"); >> ?sleep (2000); // do the serial comms with the device. >> ?System.out.println >> (System.currentTimeMillis() + name + " slept - >> closing"); >> ?cp.close(); >> ?System.out.println >> (System.currentTimeMillis() + name + " closed - >> exiting"); >> ?} catch (Exception e) { >> System.out.println ("Error in thread: " + name ); >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 mm at UDel.Edu Sat Mar 10 14:48:32 2007 From: mm at UDel.Edu (Mike Markowski) Date: Sat, 10 Mar 2007 16:48:32 -0500 Subject: [Rxtx] rxtx and Sun's comm api Message-ID: <45F327B0.2060004@udel.edu> Hi all, I joined the list a few days ago and apologize for what is likely a frequently asked question, though I haven't yet found it anywhere. I learned about rxtx.org through the readme on Sun's version 2 of their comms api. They give recommendations in that readme regarding how a better comms api should be written. Is this the aim of rxtx.org? I wrote an app on my linux box using the Sun comms api (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the fact that only linux and Solaris are supported. So I'm glad to find rxtx.org and am just reading up on how make the conversion so Windows users will be able to run the program as well. At the same time I'm just curious if rxtx.org and Sun are both heading in the same direction. Thanks for any background or historical info. Feel free to point me to any www pages if my googling has just completely missed the target! Thanks again, Mike From tjarvi at qbang.org Sat Mar 10 15:35:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 15:35:25 -0700 (MST) Subject: [Rxtx] rxtx and Sun's comm api In-Reply-To: <45F327B0.2060004@udel.edu> References: <45F327B0.2060004@udel.edu> Message-ID: On Sat, 10 Mar 2007, Mike Markowski wrote: > Hi all, > > I joined the list a few days ago and apologize for what is likely a > frequently asked question, though I haven't yet found it anywhere. I > learned about rxtx.org through the readme on Sun's version 2 of their > comms api. They give recommendations in that readme regarding how a > better comms api should be written. Is this the aim of rxtx.org? > > I wrote an app on my linux box using the Sun comms api > (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the > fact that only linux and Solaris are supported. So I'm glad to find > rxtx.org and am just reading up on how make the conversion so Windows > users will be able to run the program as well. At the same time I'm > just curious if rxtx.org and Sun are both heading in the same direction. > > Thanks for any background or historical info. Feel free to point me to > any www pages if my googling has just completely missed the target! > I do not have any news (good or bad) concerning RXTX and Sun working together but perhaps others here do. The main goal of RXTX is to expose POSIX termios interfaces to java users. The future support of javax.comm is questionable. We do not have resources for everything. gnu.io (RXTX 2.1) will be supported going forward and functions the same as CommAPI 2.0. If you have control of the source code you are working with, I would not advise using CommAPI 2.0 javax.comm. We do support CommAPI 2.0 javax.comm for older applications but I do not think that will last much longer for practical reasons. The download interest in CommAPI 2.0 javax.comm support is becomming negligible on this end. There has been discussion of a JSR effort but I do not know of any status change since it was mentioned. One problem with a JSR is that even a light weight process is going to be difficult for RXTX at this time. Maybe that will change in the future but then again it may not. For now, we are just going forward 'as is' in rxtx 2.1 with package gnu.io while trying as a secondary effort to backport the changes to rxtx 2.0 for javax.comm support for users that do not have a choice. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Mar 11 07:19:40 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 11 Mar 2007 08:19:40 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: Hi All, I have been a proponent of a JSR that makes use of RXTX. I have executed the proper agreements with Sun. At this point we are in the: Early Draft Review of Draft Specifications Stage. The best thing to do is to enter the quiet period and create a specification. The question of exactly how we, as a group, want to approach this problem, remains open. Typically, we should have both a specification and a reference implementation. Thus, it would be to our best advantage to have a nice, stable, cross platform RXTX distro that adheres to the groups specification. Now, from a specification standpoint, my personal view on the matter is that we create a series of interfaces, with nice documentation (or at least javadoc). Is this a good idea? Should we have a pure interface specification for the communication API? There are several issues, in my mind, which still weigh on us. Hot-pluggable dongles, long discovery process on pop-up ports, lack of uniformity on device names, lack of uniformity on locking, a precise understanding of how the SerialPortResourceManager works (or even if we should have one). The more questions we answer in our reference implementation, the better our specification will get. RXTX is a good working prototype, but, I don't know if that is what we want to use for a specification. Here is what I have for a CommPortInterface: */ public interface CommPortInterface { /** * @return a string representation of this port. */ String toString(); /** * Gets the name of the communications port. This name should correspond to * something the user can identify, like the label on the hardware. * @return name of the port */ String getName(); /** * @return an input stream that can be used to read data from the * communications port. If the port doesn't support reading data, this * method returns null. *

* The blocking behaviour of this input stream depends on the threshold * and timeout values, as shown below for a read buffer size of n * bytes: * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ThresholdTimeoutBlocking behaviour
StateValueStateValue
disableddisabledblock until data is available
enabledm bytesdisabledblock until min(m, n) bytes are available
disabledenabledt msblock for t ms or until data is available
enabledm bytesenabledt msblock for t ms or until min(m, n) bytes are * available
* @throws java.io.IOException */ InputStream getInputStream() throws IOException; /** * @return an output stream that can be used to send data to the * communications port. If the port doesn't support sending data, this * method returns null. * @throws java.io.IOException */ OutputStream getOutputStream() throws IOException; /** * Closes this communications port. * All PortOwnershipListeners will be? * notified of this change of ownership. Further method calls on this? * object will throw IllegalStateException. Further calls on the? * associated InputStream or OutputStream will throw IOException. *

* Close does not block. Undelivered data is discarded. Blocked read and? * write operations are aborted if the underlying operating systems? * supports an IO abort mechanism. To await the delivery of undelivered? * data call OutputStream.flush() or OutputStream.close() before calling? * Port.close(). */ void close(); /** * Enables receive threshold. * When the specified threshold number of bytes are retrieved, read will * return immediately. * * @param thresh the number of bytes in the input buffer * @throws gnu.io.UnsupportedCommOperationException * if receive threshold is * not supported by the driver * @see #disableReceiveThreshold */ void enableReceiveThreshold(int thresh) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive threshold. * * @see #enableReceiveThreshold */ void disableReceiveThreshold(); /** * @return true if receive threshold is enabled. * * @see #enableReceiveThreshold */ boolean isReceiveThresholdEnabled(); /** * @return the receive threshold value. If receive threshold is diabled * or not supported, this value is meaningless. * * @see #enableReceiveThreshold */ int getReceiveThreshold(); /** * Enables receive timeout. * When the specified number of milliseconds have elapsed, read will * return immediately. * * @param rcvTimeout the number of milliseconds to block for * @throws gnu.io.UnsupportedCommOperationException * if receive timeout is * not supported by the driver * @see #disableReceiveTimeout */ void enableReceiveTimeout(int rcvTimeout) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive timeout. * * @see #enableReceiveTimeout */ void disableReceiveTimeout(); /** * @return true if receive timeout is enabled. * * @see #enableReceiveTimeout */ boolean isReceiveTimeoutEnabled(); /** * @return the receive timeout value. If receive timeout is diabled * or not supported, this value is meaningless. * * @see #enableReceiveTimeout */ int getReceiveTimeout(); /** * Enables receive framing. * The supplied byte value in the input suggests the end of the received * frame, and read returns immediately. Only the low 8 bits of the * supplied value are significant. * * @param framingByte the frame delimiter * @throws gnu.io.UnsupportedCommOperationException * if receive framing is * not supported by the driver * @see #disableReceiveFraming */ void enableReceiveFraming(int framingByte) throws UnsupportedCommOperationException; /** * Disables receive framing. * * @see #enableReceiveFraming */ void disableReceiveFraming(); /** * @return true if receive framing is enabled. * * @see #enableReceiveFraming */ boolean isReceiveFramingEnabled(); /** * @return true if receive framing byte. If receive framing is diabled * or not supported, this value is meaningless. * * @see #enableReceiveFraming */ int getReceiveFramingByte(); /** * Sets the input buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setInputBufferSize(int size); /** * @return the input buffer size. * The driver may choose not to report correct values. */ int getInputBufferSize(); /** * Sets the output buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setOutputBufferSize(int size); /** * @return the output buffer size. * The driver may choose not to report correct values. */ int getOutputBufferSize(); } What do you think of that? Note the wishy washy nature of the spec: The driver may choose to ignore this method. Is that good enough for us? Thanks! - Doug From ra85551 at gmail.com Sun Mar 11 08:44:45 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Sun, 11 Mar 2007 17:44:45 +0300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hello, world! I am writing application that communicates with modem via AT commands. My OS is Linux Kubuntu Feisty Herd, to ensure that my application will run properly under Windows XP I installed VMWare server. When I tried to send AT command and evaluate modem answer under WinXP @ VMWare server, I actually didn't receive anything. I think that VM settings are right, because I do can communicate with modem by using standard HyperTerminall as well as I can do on native Windows. So, why RXTX doesn't work under VM, but works under Linux and pure Windows XP (i tested it there) well? The send/receive method code follows. private String sendATCommand(String command, final String waitFor, final boolean isRegex, boolean isAddCRLF, long timeout) throws BeaconConnectException { final long POLL_PERIOD = 100; final int BUFFER_SIZE = 512; final byte[] buffer = new byte[BUFFER_SIZE]; final InputStream serialInput; final OutputStream serialOutput; try { serialInput = serialPort.getInputStream(); if (command != null) { serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } } catch (IOException e) { throw new MyException("serial I/O error"); } TimerTask task = new TimerTask() { int offset = 0; int bytesRead; public synchronized void run() { try { if (serialInput.available() > 0) { bytesRead = serialInput.read(buffer, offset, BUFFER_SIZE - offset); } else { return; } } catch (IOException e) { // do nothing - maybe next time we'll read something } offset += bytesRead; if (waitFor != null) { String temporary = new String(buffer, 0, offset).trim(); if (isRegex && temporary.matches(waitFor) || temporary.contains(waitFor)) { cancel(); notify(); } } } }; Timer timer = new Timer(); timer.schedule(task, POLL_PERIOD, POLL_PERIOD); synchronized (task) { try { task.wait(timeout); task.cancel(); } catch (InterruptedException e) { } } //Cut off leading and trailing CRs, LFs and zeroes String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); System.out.println(response); return response; } -- Pavel Parkhomenko From tjarvi at qbang.org Sun Mar 11 11:48:22 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:48:22 -0600 (MDT) Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: On Sun, 11 Mar 2007, Pavel Parkhomenko wrote: > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. > > private String sendATCommand(String command, final String waitFor, > final boolean isRegex, boolean isAddCRLF, long timeout) > throws BeaconConnectException > { > final long POLL_PERIOD = 100; > final int BUFFER_SIZE = 512; > final byte[] buffer = new byte[BUFFER_SIZE]; > final InputStream serialInput; > final OutputStream serialOutput; > try > { > serialInput = serialPort.getInputStream(); > if (command != null) > { > serialOutput = serialPort.getOutputStream(); > if (isAddCRLF) > { > command += "\r\n"; > } > System.out.println(command); > serialOutput.write(command.getBytes()); > } > } > catch (IOException e) > { > throw new MyException("serial I/O error"); > } > > TimerTask task = new TimerTask() > { > int offset = 0; > int bytesRead; > public synchronized void run() > { > try > { > if (serialInput.available() > 0) > { > bytesRead = serialInput.read(buffer, offset, > BUFFER_SIZE - offset); > } > else > { > return; > } > } > catch (IOException e) > { > // do nothing - maybe next time we'll read something > } > offset += bytesRead; > if (waitFor != null) > { > String temporary = new String(buffer, 0, offset).trim(); > if (isRegex && temporary.matches(waitFor) || > temporary.contains(waitFor)) > { > cancel(); > notify(); > } > } > } > }; > > Timer timer = new Timer(); > timer.schedule(task, POLL_PERIOD, POLL_PERIOD); > synchronized (task) { > try > { > task.wait(timeout); > task.cancel(); > } > catch (InterruptedException e) > { > } > } > //Cut off leading and trailing CRs, LFs and zeroes > String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); > System.out.println(response); > return response; > } > > > Hi Pavel VMWare should not be a problem. I've used it in the past - though not with a modem. Make sure nothing else is using the modem. Then look in the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an example that should work. Note that modems could care less what OS is on top. If you are trying to match new lines to the OS and sending it to the mode for AT commands, thats probably a mistake. Also it would not hurt to print out the individual bytes that you are sending to make sure they did not get mangled along the path. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 11:55:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:55:48 -0600 (MDT) Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: On Sun, 11 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > I have been a proponent of a JSR that makes > use of RXTX. I have executed the proper agreements with Sun. > > At this point we are in the: > Early Draft Review of Draft Specifications Stage. > > The best thing to do is to enter the quiet period and create > a specification. The question of exactly how we, as a group, > want to approach this problem, remains open. > > Typically, we should have both a specification and a reference > implementation. Thus, it would be to our best advantage to have > a nice, stable, cross platform RXTX distro that adheres to the > groups specification. > > Now, from a specification standpoint, my personal view on the matter is > that we create a series of interfaces, with nice documentation (or at least > javadoc). > > Is this a good idea? Should we have a pure interface specification for > the communication API? > > There are several issues, in my mind, which still weigh on us. > Hot-pluggable dongles, long discovery process on pop-up ports, > lack of uniformity on device names, lack of uniformity on locking, > a precise understanding of how the SerialPortResourceManager > works (or even if we should have one). > > The more questions we answer in our reference implementation, the > better our specification will get. RXTX is a good working prototype, > but, I don't know if that is what we want to use for a specification. > > Here is what I have for a CommPortInterface: > */ > public interface CommPortInterface { Hi Doug, I can start going through the method interfaces later this week and giving feedback. I would suggest that the JSR should not be too generic in nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel drivers that intend to look like EIA232 ports at the kernel driver level. some ideas: EIA232PortInterface TermiosInterface SerialPortInterface Something that differentiates this from thing like USB, I2C, ... which should not have to deal with legacy serial claiming to be the comm api. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 12:52:19 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 12:52:19 -0600 (MDT) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: No news is good news with these posts. I'll start the process of pinging legal a week from Monday on my end if nobody has objections to the proposal. I just want to make sure everyone has time to raise objections. Obviously, anyone can fork from a previous version if they don't like the new license. I suspect we can avoid that though. On Sun, 4 Mar 2007, Trent Jarvi wrote: > > For those that are wondering what is going on here, this > next bit is the meat of the changes. We agreed a long time > ago to put this disclaimer in. We did a so so job. It was > in rxtx 2.0, not well written, ... So some groups using > rxtx that would like to ship rxtx so users don't need to > download, install, go to the mail-list to find why it failed, > ... Then their legal teams tell them section 5 paragraph 2 > is a show stopper. > > That was never the intent. > > > Now going through what remains... > >> and might need a (TM) suffix to make Sun happy. > > Added disclaimer at the ended 'all trademarks belong...' > >> * Line #15ff - static vs. dynamic linking - you did >> not transcribe the text from the "controlled >> interface exception" when writing this text - and >> this was good so, because these terms originally >> refer to the GPL rather than the LGPL. I think though, >> that these 4 lines are the most important ones and >> should thus be really really clear. I hope that I >> meet your original intent with the following >> suggestions: >> 1.) Instead of "A program.." it would be better to >> say "An exectuable.." in order to be closer to >> the LGPL text. > > OK. As you can see I was trying to adjust GNU text there > for the LGPL. > >> 2.) It would be better to say .. "by being dynamically >> linked with it" to clearly indicate that dynamic >> linking is meant. The matter of compilation is >> already covered by the LGPL so mentioning it again >> just leads to confusion. > > used dynamically linked terminology. > >> 3.) It would be better to say .. "is considered a >> work that uses the library in contrast to section >> 5 of the LGPL, so the terms of the LGPL do not >> apply to the resulting executable". > > I tried to address this more upfront with an intent statement. > Let me know if you have problems with it. I also tried to > make it a little more clear what was derived from the GNU > solution by moving the link location closer to GNU's suggestion. > >> >> Note that LGPL section 5 says: ..."is called a >> "work that uses the Library". Such a work, in isolation, >> is not a derivative work of the Library, and therefore >> falls outside the scope of this License." >> The next paragraph of the LGPL is exactly the problematic >> one that I hope is clarified by the exception terms you >> give. >> > > Thats the intent. Here is the combined fixes. Note that only the > material in /*-- --*/ is being touched. The new GPL license is > there but unmodified. > > > ------------------------ begin proposed new license ------------------- > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Lesser General Public > | License as published by the Free Software Foundation; either > | version 2.1 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Lesser General Public License for more details. > | > | An executable that contains no derivative of any portion of RXTX, but > | is designed to work with RXTX by being dynamically linked with it, > | is considered a "work that uses the Library" subject to the terms and > | conditions of the GNU Lesser General Public License. > | > | The following has been added to the RXTX License to remove > | any confusion about linking to RXTX. We want to allow in part what > | section 5, paragraph 2 of the LGPL does not permit in the special > | case of linking over a controlled interface. The intent is to add a > | Java Specification Request or standards body defined interface in the > | future as another exception but one is not currently available. > | > | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface > | > | As a special exception, the copyright holders of RXTX give you > | permission to link RXTX with independent modules that communicate with > | RXTX solely through the Sun Microsytems CommAPI interface version 2, > | regardless of the license terms of these independent modules, and to copy > | and distribute the resulting combined work under terms of your choice, > | provided that every copy of the combined work is accompanied by a complete > | copy of the source code of RXTX (the version of RXTX used to produce the > | combined work), being distributed under the terms of the GNU Lesser General > | Public License plus this exception. An independent module is a > | module which is not derived from or based on RXTX. > | > | Note that people who make modified versions of RXTX are not obligated > | to grant this special exception for their modified versions; it is > | their choice whether to do so. The GNU Lesser General Public License > | gives permission to release a modified version without this exception; this > | exception also makes it possible to release a modified version which > | carries forward this exception. > | > | You should have received a copy of the GNU Lesser General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > | All trademarks belong to their respective owners. > --------------------------------------------------------------------------*/ > > The original GNU Lesser General Public License Follows. > > > GNU LESSER GENERAL PUBLIC LICENSE > Version 2.1, February 1999 > > Copyright (C) 1991, 1999 Free Software Foundation, Inc. > 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > Everyone is permitted to copy and distribute verbatim copies > of this license document, but changing it is not allowed. > > [This is the first released version of the Lesser GPL. It also counts > as the successor of the GNU Library Public License, version 2, hence > the version number 2.1.] > > Preamble > > The licenses for most software are designed to take away your > freedom to share and change it. By contrast, the GNU General Public > Licenses are intended to guarantee your freedom to share and change > free software--to make sure the software is free for all its users. > > This license, the Lesser General Public License, applies to some > specially designated software packages--typically libraries--of the > Free Software Foundation and other authors who decide to use it. You > can use it too, but we suggest you first think carefully about whether > this license or the ordinary General Public License is the better > strategy to use in any particular case, based on the explanations below. > > When we speak of free software, we are referring to freedom of use, > not price. Our General Public Licenses are designed to make sure that > you have the freedom to distribute copies of free software (and charge > for this service if you wish); that you receive source code or can get > it if you want it; that you can change the software and use pieces of > it in new free programs; and that you are informed that you can do > these things. > > To protect your rights, we need to make restrictions that forbid > distributors to deny you these rights or to ask you to surrender these > rights. These restrictions translate to certain responsibilities for > you if you distribute copies of the library or if you modify it. > > For example, if you distribute copies of the library, whether gratis > or for a fee, you must give the recipients all the rights that we gave > you. You must make sure that they, too, receive or can get the source > code. If you link other code with the library, you must provide > complete object files to the recipients, so that they can relink them > with the library after making changes to the library and recompiling > it. And you must show them these terms so they know their rights. > > We protect your rights with a two-step method: (1) we copyright the > library, and (2) we offer you this license, which gives you legal > permission to copy, distribute and/or modify the library. > > To protect each distributor, we want to make it very clear that > there is no warranty for the free library. Also, if the library is > modified by someone else and passed on, the recipients should know > that what they have is not the original version, so that the original > author's reputation will not be affected by problems that might be > introduced by others. > > Finally, software patents pose a constant threat to the existence of > any free program. We wish to make sure that a company cannot > effectively restrict the users of a free program by obtaining a > restrictive license from a patent holder. Therefore, we insist that > any patent license obtained for a version of the library must be > consistent with the full freedom of use specified in this license. > > Most GNU software, including some libraries, is covered by the > ordinary GNU General Public License. This license, the GNU Lesser > General Public License, applies to certain designated libraries, and > is quite different from the ordinary General Public License. We use > this license for certain libraries in order to permit linking those > libraries into non-free programs. > > When a program is linked with a library, whether statically or using > a shared library, the combination of the two is legally speaking a > combined work, a derivative of the original library. The ordinary > General Public License therefore permits such linking only if the > entire combination fits its criteria of freedom. The Lesser General > Public License permits more lax criteria for linking other code with > the library. > > We call this license the "Lesser" General Public License because it > does Less to protect the user's freedom than the ordinary General > Public License. It also provides other free software developers Less > of an advantage over competing non-free programs. These disadvantages > are the reason we use the ordinary General Public License for many > libraries. However, the Lesser license provides advantages in certain > special circumstances. > > For example, on rare occasions, there may be a special need to > encourage the widest possible use of a certain library, so that it becomes > a de-facto standard. To achieve this, non-free programs must be > allowed to use the library. A more frequent case is that a free > library does the same job as widely used non-free libraries. In this > case, there is little to gain by limiting the free library to free > software only, so we use the Lesser General Public License. > > In other cases, permission to use a particular library in non-free > programs enables a greater number of people to use a large body of > free software. For example, permission to use the GNU C Library in > non-free programs enables many more people to use the whole GNU > operating system, as well as its variant, the GNU/Linux operating > system. > > Although the Lesser General Public License is Less protective of the > users' freedom, it does ensure that the user of a program that is > linked with the Library has the freedom and the wherewithal to run > that program using a modified version of the Library. > > The precise terms and conditions for copying, distribution and > modification follow. Pay close attention to the difference between a > "work based on the library" and a "work that uses the library". The > former contains code derived from the library, whereas the latter must > be combined with the library in order to run. > > GNU LESSER GENERAL PUBLIC LICENSE > TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION > > 0. This License Agreement applies to any software library or other > program which contains a notice placed by the copyright holder or > other authorized party saying it may be distributed under the terms of > this Lesser General Public License (also called "this License"). > Each licensee is addressed as "you". > > A "library" means a collection of software functions and/or data > prepared so as to be conveniently linked with application programs > (which use some of those functions and data) to form executables. > > The "Library", below, refers to any such software library or work > which has been distributed under these terms. A "work based on the > Library" means either the Library or any derivative work under > copyright law: that is to say, a work containing the Library or a > portion of it, either verbatim or with modifications and/or translated > straightforwardly into another language. (Hereinafter, translation is > included without limitation in the term "modification".) > > "Source code" for a work means the preferred form of the work for > making modifications to it. For a library, complete source code means > all the source code for all modules it contains, plus any associated > interface definition files, plus the scripts used to control compilation > and installation of the library. > > Activities other than copying, distribution and modification are not > covered by this License; they are outside its scope. The act of > running a program using the Library is not restricted, and output from > such a program is covered only if its contents constitute a work based > on the Library (independent of the use of the Library in a tool for > writing it). Whether that is true depends on what the Library does > and what the program that uses the Library does. > > 1. You may copy and distribute verbatim copies of the Library's > complete source code as you receive it, in any medium, provided that > you conspicuously and appropriately publish on each copy an > appropriate copyright notice and disclaimer of warranty; keep intact > all the notices that refer to this License and to the absence of any > warranty; and distribute a copy of this License along with the > Library. > > You may charge a fee for the physical act of transferring a copy, > and you may at your option offer warranty protection in exchange for a > fee. > > 2. You may modify your copy or copies of the Library or any portion > of it, thus forming a work based on the Library, and copy and > distribute such modifications or work under the terms of Section 1 > above, provided that you also meet all of these conditions: > > a) The modified work must itself be a software library. > > b) You must cause the files modified to carry prominent notices > stating that you changed the files and the date of any change. > > c) You must cause the whole of the work to be licensed at no > charge to all third parties under the terms of this License. > > d) If a facility in the modified Library refers to a function or a > table of data to be supplied by an application program that uses > the facility, other than as an argument passed when the facility > is invoked, then you must make a good faith effort to ensure that, > in the event an application does not supply such function or > table, the facility still operates, and performs whatever part of > its purpose remains meaningful. > > (For example, a function in a library to compute square roots has > a purpose that is entirely well-defined independent of the > application. Therefore, Subsection 2d requires that any > application-supplied function or table used by this function must > be optional: if the application does not supply it, the square > root function must still compute square roots.) > > These requirements apply to the modified work as a whole. If > identifiable sections of that work are not derived from the Library, > and can be reasonably considered independent and separate works in > themselves, then this License, and its terms, do not apply to those > sections when you distribute them as separate works. But when you > distribute the same sections as part of a whole which is a work based > on the Library, the distribution of the whole must be on the terms of > this License, whose permissions for other licensees extend to the > entire whole, and thus to each and every part regardless of who wrote > it. > > Thus, it is not the intent of this section to claim rights or contest > your rights to work written entirely by you; rather, the intent is to > exercise the right to control the distribution of derivative or > collective works based on the Library. > > In addition, mere aggregation of another work not based on the Library > with the Library (or with a work based on the Library) on a volume of > a storage or distribution medium does not bring the other work under > the scope of this License. > > 3. You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. To do > this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version 2, > instead of to this License. (If a newer version than version 2 of the > ordinary GNU General Public License has appeared, then you can specify > that version instead if you wish.) Do not make any other change in > these notices. > > Once this change is made in a given copy, it is irreversible for > that copy, so the ordinary GNU General Public License applies to all > subsequent copies and derivative works made from that copy. > > This option is useful when you wish to copy part of the code of > the Library into a program that is not a library. > > 4. You may copy and distribute the Library (or a portion or > derivative of it, under Section 2) in object code or executable form > under the terms of Sections 1 and 2 above provided that you accompany > it with the complete corresponding machine-readable source code, which > must be distributed under the terms of Sections 1 and 2 above on a > medium customarily used for software interchange. > > If distribution of object code is made by offering access to copy > from a designated place, then offering equivalent access to copy the > source code from the same place satisfies the requirement to > distribute the source code, even though third parties are not > compelled to copy the source along with the object code. > > 5. A program that contains no derivative of any portion of the > Library, but is designed to work with the Library by being compiled or > linked with it, is called a "work that uses the Library". Such a > work, in isolation, is not a derivative work of the Library, and > therefore falls outside the scope of this License. > > However, linking a "work that uses the Library" with the Library > creates an executable that is a derivative of the Library (because it > contains portions of the Library), rather than a "work that uses the > library". The executable is therefore covered by this License. > Section 6 states terms for distribution of such executables. > > When a "work that uses the Library" uses material from a header file > that is part of the Library, the object code for the work may be a > derivative work of the Library even though the source code is not. > Whether this is true is especially significant if the work can be > linked without the Library, or if the work is itself a library. The > threshold for this to be true is not precisely defined by law. > > If such an object file uses only numerical parameters, data > structure layouts and accessors, and small macros and small inline > functions (ten lines or less in length), then the use of the object > file is unrestricted, regardless of whether it is legally a derivative > work. (Executables containing this object code plus portions of the > Library will still fall under Section 6.) > > Otherwise, if the work is a derivative of the Library, you may > distribute the object code for the work under the terms of Section 6. > Any executables containing that work also fall under Section 6, > whether or not they are linked directly with the Library itself. > > 6. As an exception to the Sections above, you may also combine or > link a "work that uses the Library" with the Library to produce a > work containing portions of the Library, and distribute that work > under terms of your choice, provided that the terms permit > modification of the work for the customer's own use and reverse > engineering for debugging such modifications. > > You must give prominent notice with each copy of the work that the > Library is used in it and that the Library and its use are covered by > this License. You must supply a copy of this License. If the work > during execution displays copyright notices, you must include the > copyright notice for the Library among them, as well as a reference > directing the user to the copy of this License. Also, you must do one > of these things: > > a) Accompany the work with the complete corresponding > machine-readable source code for the Library including whatever > changes were used in the work (which must be distributed under > Sections 1 and 2 above); and, if the work is an executable linked > with the Library, with the complete machine-readable "work that > uses the Library", as object code and/or source code, so that the > user can modify the Library and then relink to produce a modified > executable containing the modified Library. (It is understood > that the user who changes the contents of definitions files in the > Library will not necessarily be able to recompile the application > to use the modified definitions.) > > b) Use a suitable shared library mechanism for linking with the > Library. A suitable mechanism is one that (1) uses at run time a > copy of the library already present on the user's computer system, > rather than copying library functions into the executable, and (2) > will operate properly with a modified version of the library, if > the user installs one, as long as the modified version is > interface-compatible with the version that the work was made with. > > c) Accompany the work with a written offer, valid for at > least three years, to give the same user the materials > specified in Subsection 6a, above, for a charge no more > than the cost of performing this distribution. > > d) If distribution of the work is made by offering access to copy > from a designated place, offer equivalent access to copy the above > specified materials from the same place. > > e) Verify that the user has already received a copy of these > materials or that you have already sent this user a copy. > > For an executable, the required form of the "work that uses the > Library" must include any data and utility programs needed for > reproducing the executable from it. However, as a special exception, > the materials to be distributed need not include anything that is > normally distributed (in either source or binary form) with the major > components (compiler, kernel, and so on) of the operating system on > which the executable runs, unless that component itself accompanies > the executable. > > It may happen that this requirement contradicts the license > restrictions of other proprietary libraries that do not normally > accompany the operating system. Such a contradiction means you cannot > use both them and the Library together in an executable that you > distribute. > > 7. You may place library facilities that are a work based on the > Library side-by-side in a single library together with other library > facilities not covered by this License, and distribute such a combined > library, provided that the separate distribution of the work based on > the Library and of the other library facilities is otherwise > permitted, and provided that you do these two things: > > a) Accompany the combined library with a copy of the same work > based on the Library, uncombined with any other library > facilities. This must be distributed under the terms of the > Sections above. > > b) Give prominent notice with the combined library of the fact > that part of it is a work based on the Library, and explaining > where to find the accompanying uncombined form of the same work. > > 8. You may not copy, modify, sublicense, link with, or distribute > the Library except as expressly provided under this License. Any > attempt otherwise to copy, modify, sublicense, link with, or > distribute the Library is void, and will automatically terminate your > rights under this License. However, parties who have received copies, > or rights, from you under this License will not have their licenses > terminated so long as such parties remain in full compliance. > > 9. You are not required to accept this License, since you have not > signed it. However, nothing else grants you permission to modify or > distribute the Library or its derivative works. These actions are > prohibited by law if you do not accept this License. Therefore, by > modifying or distributing the Library (or any work based on the > Library), you indicate your acceptance of this License to do so, and > all its terms and conditions for copying, distributing or modifying > the Library or works based on it. > > 10. Each time you redistribute the Library (or any work based on the > Library), the recipient automatically receives a license from the > original licensor to copy, distribute, link with or modify the Library > subject to these terms and conditions. You may not impose any further > restrictions on the recipients' exercise of the rights granted herein. > You are not responsible for enforcing compliance by third parties with > this License. > > 11. If, as a consequence of a court judgment or allegation of patent > infringement or for any other reason (not limited to patent issues), > conditions are imposed on you (whether by court order, agreement or > otherwise) that contradict the conditions of this License, they do not > excuse you from the conditions of this License. If you cannot > distribute so as to satisfy simultaneously your obligations under this > License and any other pertinent obligations, then as a consequence you > may not distribute the Library at all. For example, if a patent > license would not permit royalty-free redistribution of the Library by > all those who receive copies directly or indirectly through you, then > the only way you could satisfy both it and this License would be to > refrain entirely from distribution of the Library. > > If any portion of this section is held invalid or unenforceable under any > particular circumstance, the balance of the section is intended to apply, > and the section as a whole is intended to apply in other circumstances. > > It is not the purpose of this section to induce you to infringe any > patents or other property right claims or to contest validity of any > such claims; this section has the sole purpose of protecting the > integrity of the free software distribution system which is > implemented by public license practices. Many people have made > generous contributions to the wide range of software distributed > through that system in reliance on consistent application of that > system; it is up to the author/donor to decide if he or she is willing > to distribute software through any other system and a licensee cannot > impose that choice. > > This section is intended to make thoroughly clear what is believed to > be a consequence of the rest of this License. > > 12. If the distribution and/or use of the Library is restricted in > certain countries either by patents or by copyrighted interfaces, the > original copyright holder who places the Library under this License may add > an explicit geographical distribution limitation excluding those countries, > so that distribution is permitted only in or among countries not thus > excluded. In such case, this License incorporates the limitation as if > written in the body of this License. > > 13. The Free Software Foundation may publish revised and/or new > versions of the Lesser General Public License from time to time. > Such new versions will be similar in spirit to the present version, > but may differ in detail to address new problems or concerns. > > Each version is given a distinguishing version number. If the Library > specifies a version number of this License which applies to it and > "any later version", you have the option of following the terms and > conditions either of that version or of any later version published by > the Free Software Foundation. If the Library does not specify a > license version number, you may choose any version ever published by > the Free Software Foundation. > > 14. If you wish to incorporate parts of the Library into other free > programs whose distribution conditions are incompatible with these, > write to the author to ask for permission. For software which is > copyrighted by the Free Software Foundation, write to the Free > Software Foundation; we sometimes make exceptions for this. Our > decision will be guided by the two goals of preserving the free status > of all derivatives of our free software and of promoting the sharing > and reuse of software generally. > > NO WARRANTY > > 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO > WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. > EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR > OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY > KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE > IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE > LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME > THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. > > 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN > WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY > AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU > FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR > CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE > LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING > RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A > FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF > SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH > DAMAGES. > > END OF TERMS AND CONDITIONS > > How to Apply These Terms to Your New Libraries > > If you develop a new library, and you want it to be of the greatest > possible use to the public, we recommend making it free software that > everyone can redistribute and change. You can do so by permitting > redistribution under these terms (or, alternatively, under the terms of the > ordinary General Public License). > > To apply these terms, attach the following notices to the library. It is > safest to attach them to the start of each source file to most effectively > convey the exclusion of warranty; and each file should have at least the > "copyright" line and a pointer to where the full notice is found. > > > Copyright (C) > > This library is free software; you can redistribute it and/or > modify it under the terms of the GNU Lesser General Public > License as published by the Free Software Foundation; either > version 2.1 of the License, or (at your option) any later version. > > This library is distributed in the hope that it will be useful, > but WITHOUT ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > Lesser General Public License for more details. > > You should have received a copy of the GNU Lesser General Public > License along with this library; if not, write to the Free Software > Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > > Also add information on how to contact you by electronic and paper mail. > > You should also get your employer (if you work as a programmer) or your > school, if any, to sign a "copyright disclaimer" for the library, if > necessary. Here is a sample; alter the names: > > Yoyodyne, Inc., hereby disclaims all copyright interest in the > library `Frob' (a library for tweaking knobs) written by James Random Hacker. > > , 1 April 1990 > Ty Coon, President of Vice > > That's all there is to it! > ------------------------ end of proposed license ------------------ > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From gjhanna at gmail.com Sun Mar 11 14:21:17 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Mon, 12 Mar 2007 09:21:17 +1300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hi Pavel, We are using RXTX under VMWare server in production, quite satisfactorily. We're using Red Hat Enterprise Server 4, and ... Whatever the "enterprise" VMWare product is. Regards, Greg H > Subject: [Rxtx] RXTX under VMWare server > To: rxtx at qbang.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. [ ... snip ... ] -- Pavel Parkhomenko -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070311/4cebb6f9/attachment-0007.html From gergg at cox.net Sun Mar 11 23:39:19 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 12 Mar 2007 00:39:19 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: <45F4E787.6050502@cox.net> Trent Jarvi wrote: > I can start going through the method interfaces later this week and giving > feedback. I would suggest that the JSR should not be too generic in > nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel > drivers that intend to look like EIA232 ports at the kernel driver level. > > some ideas: > > EIA232PortInterface > TermiosInterface > SerialPortInterface > > Something that differentiates this from thing like USB, I2C, ... which > should not have to deal with legacy serial claiming to be the comm api. I'm going to throw out a suggestion, which I am mostly serious about. What would happen if we took the appropriate bits of the J2ME connector API, and just used that as the new COMM API so that finally JSE and JME had a common foundation for these kinds of things? Gregg Wonderly From ra85551 at gmail.com Mon Mar 12 09:08:37 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Mon, 12 Mar 2007 18:08:37 +0300 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Should any application use the modem, HyperTerminal won't be able to talk to the modem. But it actually can send and receive AT comands, while my application cannot :-( > Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Thansk for the reference. I examined that example and found that there's no significant differences between my read/write implementation and that one, except that SimpleSnuV1 listens for serialEvent's, but not for sake of data retrieval, just for printing them out - I don't know why ;-) > Note that modems could care less what OS is on top. If you are trying to > match new lines to the OS and sending it to the mode for AT commands, > thats probably a mistake. I do send strings to serial port, not to OS, and do try to get answers back. If it is the mistake, what's the right way? > Also it would not hurt to print out the > individual bytes that you are sending to make sure they did not get > mangled along the path. Yeah, I am printing these bytes before doing write, but it means that I only see what I intend to write. How can I ensure that these bytes have gone out of the box and reached my modem? BTW, I found that my send/receive method is complex enough, so I've rewritten it. Please, see the following code and point any mistakes, because I don't know where can they remain yet. private static final int LARGE_TIMEOUT = 15000; private static final int SMALL_TIMEOUT = 500; ... private String sendATCommand(String command, String waitFor, boolean isRegex, boolean isAddCRLF) throws BeaconConnectException { byte[] buffer = new byte[512]; int offset; String result = ""; try { if (waitFor != null) { serialPort.enableReceiveTimeout(LARGE_TIMEOUT); } else { serialPort.enableReceiveTimeout(SMALL_TIMEOUT); } if (command != null) { OutputStream serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } offset = 0; InputStream serialInput = serialPort.getInputStream(); while (serialInput.available() != -1) { int bytesRead = serialInput.read(buffer, offset, buffer.length - offset); if (bytesRead == 0) { break; } offset += bytesRead; result = new String(buffer, 0, offset).trim(); if (waitFor != null) { System.out.println(result); if (isRegex && result.matches(waitFor) || result.contains(waitFor)) { break; } } } } catch (UnsupportedCommOperationException e) { throw new MyException("unsupported operation"); } catch (IOException e) { throw new MytException("serial I/O error"); } return result; } -- Pavel Parkhomenko From clayno at hotpop.com Thu Mar 15 02:47:34 2007 From: clayno at hotpop.com (Christopher Layno) Date: Thu, 15 Mar 2007 16:47:34 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi, we're using the latest release of rxtx (2.1-7r2) for our system that has two applications using the library. one application sends requests to the modem while the other simply checks the modem status. we deployed our system on a pentium machine with red hat linux 9.0 installed. now the problem arises when these two applications try to access the same modem at the same time. one of them will eventually have to throw the PortInUseException as shown below: 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException gnu.io.PortInUseException: root PID = 743 Program = java root PID = 743 Program = java root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) this was expected. what we didn't expect though was that if we repeat the scenario 5 times, always 5 times, the application would also throw a VM error: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4473CD21 Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so Current Java thread: at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) - locked <0x44cfd4c8> (a gnu.io.CommPortIdentifier) at ************ at ************ - locked <0x4476a468> (a **********) at ************ at ************ at ************ at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java :261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages( TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run( TCPTransport.java:701) at java.lang.Thread.run(Thread.java:534) note: i replaced some sensitive data with asterisks our team has looked everywhere on the internet, including your mail archives, for a solution to this problem but to no avail. i really hope you could help us out on this one. thanks in advance! best regards, chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070315/1936460a/attachment-0007.html From tjarvi at qbang.org Fri Mar 16 04:30:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 04:30:25 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: On Thu, 15 Mar 2007, Christopher Layno wrote: > hi, > > we're using the latest release of rxtx (2.1-7r2) for our system that has two > applications using the library. one application sends requests to the modem > while the other simply checks the modem status. we deployed our system on a > pentium machine with red hat linux 9.0 installed. > > now the problem arises when these two applications try to access the same > modem at the same time. one of them will eventually have to throw the > PortInUseException as shown below: > > 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException > gnu.io.PortInUseException: root PID = 743 Program = java root PID = > 743 Program = java root PID = 743 Program = ??? root PID = 743 Program > = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root > PID = 743 Program = ??? root PID = 743 Program = ??? > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > > this was expected. what we didn't expect though was that if we repeat the > scenario 5 times, always 5 times, the application would also throw a VM > error: > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x4473CD21 > Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 > Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so > > Current Java thread: > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) Hi Chris The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. The code is originally by Werner Almesberger. He gave us permission to use it in rxtx. You might look at what has changed since 1998 in his fuser application. Or you can just do like other OSs and do the following in fuserImp.c JNIEXPORT jstring JNICALL Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv *env, jobject obj, jstring arg) { return (*env)->NewStringUTF(env, "Unknown Application"); } It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. -- Trent Jarvi tjarvi at qang.org From Adrien.TOS at ingenico.com Fri Mar 16 05:11:12 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Fri, 16 Mar 2007 12:11:12 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903CBC312@frsnprexc1.usr.ingenico.loc> Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070316/972ab214/attachment-0007.html From joachim at buechse.de Fri Mar 16 05:13:24 2007 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 16 Mar 2007 12:13:24 +0100 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. From tjarvi at qbang.org Fri Mar 16 16:36:29 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 16:36:29 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Fri Mar 16 16:02:23 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 16 Mar 2007 18:02:23 -0400 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Not all platforms are Unix based. Also mixing native library usage and command-line calls is not an elegant solution, IMHO. One or the other, but not both. Andre On 16-Mar-07, at 07:13 , Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is > trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We >> only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From clayno at hotpop.com Sun Mar 18 22:17:28 2007 From: clayno at hotpop.com (Christopher Layno) Date: Mon, 19 Mar 2007 12:17:28 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi everyone, thank you so much for your replies. they were really helpful. anyway, before i sent the email, my team was already implementing a temporary solution by using joachim's suggestion. we invoked a lsof command from our java code although i share the same concern with trent and andre-john about portability issues. that's why i said it's just temporary. my superiors have yet to approve our bug fix. so my question now is this: is recompiling the rxtx source code the only way to solve this problem? because if it's the only solution, then i think my superiors would rather have a new release from the rxtx community itself that fixes this bug(?) rather than have my team recompile the source code. best regards, chris Trent Jarvi wrote: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. ... It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070318/237463b2/attachment-0007.html From tjarvi at qbang.org Mon Mar 19 16:20:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Mar 2007 16:20:52 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: Hi Chris I can compile a new version after the 21st if you do not feel comfortable doing so. Please send me an email reminder off-line then. On Mon, 19 Mar 2007, Christopher Layno wrote: > hi everyone, > > thank you so much for your replies. they were really helpful. > > anyway, before i sent the email, my team was already implementing a > temporary solution by using joachim's suggestion. > we invoked a lsof command from our java code although i share the same > concern with trent and andre-john about > portability issues. that's why i said it's just temporary. my superiors have > yet to approve our bug fix. > > so my question now is this: is recompiling the rxtx source code the only way > to solve this problem? because if it's the only > solution, then i think my superiors would rather have a new release from the > rxtx community itself that fixes this bug(?) > rather than have my team recompile the source code. > > best regards, > > chris > > Trent Jarvi wrote: > > Hi Joachim > > It would be nice to have that functionality but calling the program > introduces too many issues imho. Explaining to someone why rxtx invoked a > rogue lsof does not sound very interesting. > > On Fri, 16 Mar 2007, Joachim Buechse wrote: > > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: > > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. > > _______________________________________________ > Rxtx mailing list > Rxtx 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 Eric.Arseneau at sun.com Tue Mar 20 11:47:33 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Tue, 20 Mar 2007 10:47:33 -0700 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 Message-ID: <46001E35.9040608@sun.com> Anyone have any experience with RXTX working with JDK 6 on other platforms ? From mm at UDel.Edu Tue Mar 20 12:18:29 2007 From: mm at UDel.Edu (Mike Markowski) Date: Tue, 20 Mar 2007 14:18:29 -0400 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 In-Reply-To: <46001E35.9040608@sun.com> References: <46001E35.9040608@sun.com> Message-ID: <46002575.4000306@udel.edu> Eric Arseneau wrote: > Anyone have any experience with RXTX working with JDK 6 on other platforms ? I'm using 32 bit intel, gentoo linux, jdk6 with no problems. My applications only use a serial port, though, nothing on the parallel port. Mike From falko.guderian at gmx.de Wed Mar 21 08:17:35 2007 From: falko.guderian at gmx.de (Falko Guderian) Date: Wed, 21 Mar 2007 15:17:35 +0100 Subject: [Rxtx] RXTX binaries for SH4 Message-ID: <46013E7F.40102@gmx.de> Dear developers, I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no possiblities to compile the source code. Better, I'm not able to do this at the moment. Can you provide me with rxtxSerial.dll (SH4) in the rxtx-2.1-8-testing version? (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) The reason for the testing version is I need custom baud rates. Thanks for help. Kind regards, Falko Guderian From tjarvi at qbang.org Wed Mar 21 21:38:37 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Mar 2007 21:38:37 -0600 (MDT) Subject: [Rxtx] RXTX binaries for SH4 In-Reply-To: <46013E7F.40102@gmx.de> References: <46013E7F.40102@gmx.de> Message-ID: On Wed, 21 Mar 2007, Falko Guderian wrote: > Dear developers, > > I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no > possiblities to compile the source code. Better, I'm not able to do this > at the moment. Can you provide me with rxtxSerial.dll (SH4) in the > rxtx-2.1-8-testing version? > (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) > > The reason for the testing version is I need custom baud rates. > > Thanks for help. > Hi Falko WinCE binary format is not supported by gcc. That makes compiling limited to those familiar with the WinCE tools. I hope someone is able to provide them for you but it is not likely. WinCE has been compiled by others in the past but rxtx.org builds have never included WinCE. There is some information with the source concerning WinCE builds if you decide to do it. We can share your results too if you like. The source in the WinCE has never been updated for the custom baud rate. That would need changes from the main source I presume. If you look at the source, you will note that Michal Hobot created a mini fork in the source to handle wince but it has not been updated for 3 years. -- Trent Jarvi tjarvi at qbang.org From Adrien.TOS at ingenico.com Thu Mar 22 07:08:55 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Thu, 22 Mar 2007 14:08:55 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Hi everybody, Do you have any comments on this issue? Thanks! AT ________________________________ De : Adrien TOS Envoy? : vendredi 16 mars 2007 12:11 ? : 'rxtx at qbang.org' Cc : Adrien TOS Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070322/2306c538/attachment-0007.html From jeremy.reeve at zen.co.uk Mon Mar 19 07:36:04 2007 From: jeremy.reeve at zen.co.uk (Jeremy S. Reeve) Date: Mon, 19 Mar 2007 13:36:04 +0000 Subject: [Rxtx] rxtx failing to compile on Fedora Core 6 Message-ID: <1174311364.21865.6.camel@d9thc> When trying to compile latest source : rxtx-2.1-7r2 I get the following when running configure: ---------------- checking os.version 2.6.18-1.2200.fc5smp WARNING: configure is having a hard time determining which directory contains the file jni_md.h. Edit Makefile and fix the variable JAVANATINC to point to the correct directory. The following options are available: /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/ /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/linux/ If there are more than one option available the first was selected. WARNING: Kernel include files do not match the current kernel configure: creating ./config.status ------------------------ which seems OK checking the resultant Makefile but when attempting to build with gmake install I get the following output : ---------------------- 34 problems (34 warnings)/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/javah -classpath .:/home/jsr/rxtxsrc/rxtx-2.1-7r2:/home/jsr/rxtxsrc/rxtx-2.1-7r2/src:/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/ext/RXTXcomm.jar -d i686-pc-linux-gnu -jni `(for i in CommDriver CommPortEnumerator CommPortIdentifier CommPort CommPortOwnershipListener Configure I2C I2CPortEvent I2CPortEventListener I2CPort LPRPort NoSuchPortException ParallelPortEvent ParallelPortEventListener ParallelPort PortInUseException Raw RawPortEvent RawPortEventListener RawPort RS485 RS485PortEvent RS485PortEventListener RS485Port RXTXCommDriver RXTXPort RXTXVersion SerialPortEvent SerialPortEventListener SerialPort UnsupportedCommOperationException UnSupportedLoggerException Zystem;do \ if grep > /dev/null native.* \( /home/jsr/rxtxsrc/rxtx-2.1-7r2/./src/$i.java; then \ echo gnu.io.$i; \ fi; \ done)` i686-pc-linux-gnu/gnu_io_CommPortIdentifier.h: No such file or directory make: *** [/home/jsr/rxtxsrc/rxtx-2.1-7r2/gnu/io/CommDriver.class] Error 1 ------------------------ Any ideas or pointers? Regards, Jeremy From tjarvi at qbang.org Sat Mar 24 08:12:54 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 Mar 2007 08:12:54 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > From Adrien.TOS at ingenico.com Sat Mar 24 11:53:22 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Sat, 24 Mar 2007 18:53:22 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> I do not have the threshold setting enabled, I have explicitely disabled it with: port_.disableReceiveThreshold(); I have also run the same tests with the threshold setting enabled, but they also fail in the same way as described below. So it seems there is a problem with timeout handling on Win32? ________________________________ From: rxtx-bounces at qbang.org on behalf of Trent Jarvi Sent: Sat 3/24/2007 3:12 PM To: RXTX Developers and Users Subject: Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 8312 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20070324/f9e39c9b/attachment-0007.bin From greg.johnson at manchester.ac.uk Sun Mar 25 13:41:36 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Sun, 25 Mar 2007 21:41:36 +0200 Subject: [Rxtx] Mac intel weirdness Message-ID: Hi folks, I'm trying to get rxtx to work on my macbook pro with a USB-serial dongle on it. I am using the 2.1-8 code from the CVS (though it seems to report itself as 2.1-7: makes it difficult to prove to oneself that the changes have 'taken'! - line 4210 in SerialImp.c, line 40 in RXTXVersion.java) I am trying the 2.1-8 because of horrible lock problems in 2.1-7. However, the serialport closure code seems to be broken - it won't close because it believes the (previously opened!) port doesn't exist. Here is what I'm trying: 0. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "false" 1. Open a port Serialport serialport = (SerialPort) commportidentifier.open ("test",100); 2. Talk to a device ... 3. Close port serialport.close(); 4. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "true" - why is this? 5. Try to reopen port Serialport serialport2 = (SerialPort) commportidentifier.open("test", 100); throws PortInUseException. I've dug around a bit in the source, and it seems the SerialPort.close () should call the CommPortIdentifier.internalClosePort() (line 67 of CommPort.java). However, I crash out with the NoSuchPortException when getPortIdentifier is called. Which seems quite weird to me, seeing as it is called on this - which was create just beforehand. Does anyone know how to fix this? Cheers, greg From knute at frazmtn.com Sat Mar 24 10:32:38 2007 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 24 Mar 2007 09:32:38 -0700 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc>, Message-ID: <4604F036.17833.135298@knute.frazmtn.com> > >The behavior of timeout depends upon the setting of the threshold. Do you >have the threshold setting? > This is the same bug I reported last fall. There was a fellow that sent me an email asking if it had been fixed. I told him I didn't think so. He got somebody to write a fix for him but I have not been able to contact him again for the actual changes. The inaccurate timeout and the failure of blocking when no timeouts are set is a serious bug in my humble opinion and renders the software unusable for my applications. I'd really like to have an alternative to the Sun comm api but there just isn't one that I know of. -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Mar 26 16:17:00 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 26 Mar 2007 16:17:00 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> Message-ID: >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. From ra85551 at gmail.com Tue Mar 27 10:18:36 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Tue, 27 Mar 2007 20:18:36 +0400 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Ultimately I found a solution. At first, that wasn't actually the VMWare + WinXP + RXTX issue, that was WinXP + RXTX issue. But on pure XP it sometimes workes, sometimes not, while under VMWare I had never seen my snippet working at all. SimpleSnuV1.java would not help me, because there is only one line I missed, and SimpleSnuV1.java also doesn't contain it! It is as follows: serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_OUT | SerialPort.FLOWCONTROL_RTSCTS_IN); Thank you for your attention. -- Pavel Parkhomenko From griff at op.pl Wed Mar 28 01:28:19 2007 From: griff at op.pl (griff@op.pl) Date: Wed, 28 Mar 2007 09:28:19 +0200 Subject: [Rxtx] No blocking read on Windows. Message-ID: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/5d07d571/attachment-0007.html -------------- next part -------------- Hi, I have problem that InputStram.read() (SerialPort)?returns -1 instead blocking and waiting for data. I found that this problem was ?known in 2005 : ? >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > >> Hi Trent >> >> Thanks for the fast response. >> Here's a Q&D test program for the blocking read on windows that just >> attempts to read one byte, and prints the resulting byte. On my system it >> returns -1, where I expect that it keeps waiting for data. >> >This isn't happening on Linux so the bug is in src/termios.c.? I'll have >something this weekend to fix that. I'm using RXTX 2.1.7r2 and the problem still is here. Im using Windows XP and java 1.5 disableReciveTimeout() and disableReciveTreshhold() dont help. ? best regards ? Piotr Zielniok From Adrien.TOS at ingenico.com Wed Mar 28 01:40:46 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Wed, 28 Mar 2007 09:40:46 +0200 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903E88880@frsnprexc1.usr.ingenico.loc> Looking at the code, it seems there is no support for infinite timeout? And maybe the count++ < 20 condition is breaking out of the loop too early? The only condition to break out of the loop should either be the timeout has expired or the number of requested bytes has been received. -----Message d'origine----- De : rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] De la part de Trent Jarvi Envoy? : mardi 27 mars 2007 00:17 ? : RXTX Developers and Users Objet : Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From j.kenneth.gentle at acm.org Wed Mar 28 06:44:15 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 28 Mar 2007 08:44:15 -0400 Subject: [Rxtx] No blocking read on Windows. In-Reply-To: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> References: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> Message-ID: <200703281844.l2SIiITW028614@qbang.org> Just another "ME TOO!" - I'm seeing this problem on Windows XP, jre for windows XP/Embedded. I cranked receiveTimeout up to Integer.MAX_INT, but it doesn't seem to wait that long At 03:28 2007-03-28, you wrote: >Hi, >I have problem that InputStram.read() (SerialPort) returns -1 >instead blocking and waiting for data. I found that this problem >was known in 2005 : > > >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > > > >> Hi Trent > >> > >> Thanks for the fast response. > >> Here's a Q&D test program for the blocking read on windows that just > >> attempts to read one byte, and prints the resulting byte. On my system it > >> returns -1, where I expect that it keeps waiting for data. > >> > > >This isn't happening on Linux so the bug is in src/termios.c. I'll have > >something this weekend to fix that. > >I'm using RXTX 2.1.7r2 and the problem still is here. >Im using Windows XP and java 1.5 >disableReciveTimeout() and disableReciveTreshhold() dont help. > >best regards > >Piotr Zielniok > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From greg.johnson at manchester.ac.uk Wed Mar 28 14:43:29 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Wed, 28 Mar 2007 22:43:29 +0200 Subject: [Rxtx] Cannot close and reopen serial port Message-ID: <377F9765-7A9D-4CE9-9176-FFB63A2594F0@manchester.ac.uk> Dear all, It appears I cannot close a port properly: SerialPort serialport = portid.open("myprog",100); // do some stuff, all works fine serialport.close(); // all seems fine but... SerialPort sp2 = portid.open("myprog",100); throws PortInUseException. And when I dig into the rxtx code, I find in CommPort.java, in close(): CommPortIdentifier cp = CommPortIdentifier.getPortIdentifier(this); (line 64 or there abouts) but this throws a NoSuchPortException which is caught but ignored (line 74ish). Can anyone suggest how this could happen: a port that was valid, opened, and used, throws a NSPE when it comes to closing it? I'm pulling my (remaining) hair out over this one! Cheers, greg PS And thanks for RXTX - it's great to have! PPS (21.-7. winxp/osx both, java 1.5) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/c28852fc/attachment-0007.html From rxtx at vrijheidslaan.net Fri Mar 30 16:52:50 2007 From: rxtx at vrijheidslaan.net (Rob) Date: Fri, 30 Mar 2007 22:52:50 -0000 Subject: [Rxtx] Cvs Question Message-ID: <61896.80.126.150.87.1175295162.squirrel@webmail.provalue.nl> Hi There, Im trying to get the latest version to work on mac osx. Problem is that i can't checkout version 2.1.8. Probably my fault but can some one please give me the alternative commands for: [user at myhost]$ export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot [user at myhost]$ cvs login Thanx, Rob From ra85551 at gmail.com Thu Mar 1 03:47:06 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Thu, 1 Mar 2007 13:47:06 +0300 Subject: [Rxtx] enableReceiveTimeout() issue Message-ID: Hello, world! I found a limitation of 16300 ms for CommPort's enableReceiveTimeout() method, while in original javax.comm docs there are no any references to that. Is that a bug or feature? I actually need longer timeouts sometimees. -- Pavel Parkhomenko From lyon at docjava.com Thu Mar 1 07:54:17 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 01 Mar 2007 09:54:17 -0500 Subject: [Rxtx] parametric singleton design pattern In-Reply-To: References: <22d55aea0702081207q5e7f6785l352d498d6f5f9fb1@mail.gmail.com> <22d55aea0702100034o3bcf42f3j1d1a6257029a67b0@mail.gmail.com> Message-ID: Hi All, I have been thinking about the use of a design pattern to cache resources that are consumed by processes. Toward that end, I have arrived at a parametric singleton design pattern, which I mentioned on this list some time ago. The idea has been published at: http://www.jot.fm/issues/issue_2007_03/column2 I can't help but think that there should be an API available for dealing with the tracking of serial port usage. Perhaps it is a kind of resource manager called the: SerialPortManager basic prototypes already exist in this vain. See, for example: http://www.ce.rit.edu/research/projects/2005_fall/rt_poolsystem/doc/PoolMon/SerialPortManager.html http://www.eventhelix.com/RealtimeMantra/PatternCatalog/serial_port_design_pattern.htm And others shown by a google search on "SerialPortManager" Cheers! - Doug From Eric.Arseneau at sun.com Thu Mar 1 10:15:03 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:15:03 -0800 Subject: [Rxtx] Any known Java 6 issues with RXTX 2.1-7r2 ? Message-ID: <45E70A17.1060206@sun.com> I just did a test on a recent build of Solaris 11 x86 and it seems that I can connect to my serial device fine when Java 5 is the default, but when Java 6 is the default, no go. Any information ? From Eric.Arseneau at sun.com Thu Mar 1 10:19:58 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:19:58 -0800 Subject: [Rxtx] Mac OS X and missing data Message-ID: <45E70B3E.7040908@sun.com> We have a device which is USB based but presents itself as a serial port to a machine. On my MacBook Pro I can get excellent throughput if I get my device to send data as quickly as possible. On the desktop side, if I do an type of disk IO to log the data I get, I end up with some missing data at some point. I hooked up a USB analyzer and did confirm that all the data is sent as expected to the desktop from the device. I found a work around for this, buffer the data in memory and only write the data out when I've received it all. However, when the same code and same device is attempted on a co-workers MacBook Pro (same hardware specs), I get errors and must slow down dramatically the device side's sending of data. Any ideas/recommendations on what I can do to get rid of this error ? From what I can tell, it seems that RXTX is not able to wake up to the interrupts coming in indicating data is ready, quickly enough, is there anything I can do ? From chinkaiw at hotmail.com Fri Mar 2 00:57:43 2007 From: chinkaiw at hotmail.com (Wang Chinkai) Date: Fri, 02 Mar 2007 07:57:43 +0000 Subject: [Rxtx] dynamic detect rs232 port Message-ID: Hi all I have a question about detecting rs232 port dynamicly. I have to aceess some port and detect rs232 port at the same time. Some usb device simulates rs232 port , and I can not know what the port name it gets until it connects,so I have to detect it dynamic,but I have to access another rs232 device at the same time. I found a problem. If I use CommPortIdentifier.getPortIdentifiers() to get new port list , and the other rs232 access function will not close port correctly. So , How can I solve it . Thanks. _________________________________________________________________ ?? 2GB ???? Windows Live Mail ????????????? http://ideas.live.com/programpage.aspx?versionid=5d21c51a-b161-4314-9b0e-4911fb2b2e6d From eu259473 at tele2.it Fri Mar 2 06:16:40 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 02 Mar 2007 14:16:40 +0100 Subject: [Rxtx] rxtx on HP tru 64 unix Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070302/706c7a70/attachment-0008.html From tjarvi at qbang.org Fri Mar 2 08:39:33 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 08:39:33 -0700 (MST) Subject: [Rxtx] rxtx on HP tru 64 unix In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, "Giuseppe Marchese" wrote: > Hi > > I try to install rxtx on hp tru 64 but make fails, > There are somebody that do the same and work. > > > Sorry for may english! > > Hi Giuseppe Could you provide a log of the failure? script ./configure make # use gnu make exit The information will be in the typescript created. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 2 19:56:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 19:56:52 -0700 (MST) Subject: [Rxtx] dynamic detect rs232 port In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, Wang Chinkai wrote: > Hi all > > I have a question about detecting rs232 port dynamicly. > > I have to aceess some port and detect rs232 port at the same time. > Some usb device simulates rs232 port , and I can not know > what the port name it gets until it connects,so I have to detect it > dynamic,but I have to access > another rs232 device at the same time. > > I found a problem. Hi Wang This is a known problem. The code is braindead there. In fact there needs to be events even in a rudamentary way when you add a usb dongle. I'm burried in tasks not far from rxtx but not in rxtx. I can't get to the problem but we would accept patches if you dig into it. [I'm getting to the license question earlier too; I don't have another 10%] -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Fri Mar 2 23:19:01 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 01:19:01 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Hi, Under ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable USB -> serial converter(using virtual com port drivers), with using example code pretty much straight out of http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port opens fine, enumerations all work, etc. My application calls for a large amount of data to be transferred in a short amount of time at 2,000,000 baud. My hardware sends approximately 15,232 bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL converter work fine, and the application works using C++. In C++, I do a hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); to open the port, and a boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); to read the port. The variable buffer fills with the 15238 bytes, and returns. If I do a resultz = is.read(cbuf,0,15238); in java with RXTX where is = new BufferedReader(new InputStreamReader(port.getInputStream())); and where resultz is an int, and cbuf is a char [] cbuf, resultz gets EXACTLY 3968 bytes the first time called. If I call it multiple times, I get roughly 11k total(less than what is sent), never more than the 3968 bytes per is.read() call. My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 bytes. I've played with inputbuffersize, receive threshold, receivetimeout, and so on. The FTDI virtual com port drivers that I'm using are rock solid, and have had zero problems with them using a variety of applications, some of my own, some professionally written, etc. No flow control is used anyplace, no RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. No exceptions are being thrown. What am I doing wrong, and what I can adjust to receive the full 15k bytes in one single read? Thanks! Keith From Eric.Arseneau at sun.com Fri Mar 2 23:32:07 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Fri, 02 Mar 2007 22:32:07 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <45E91667.20501@sun.com> This is the same type of thing that is happening to me on Mac OS X and does not seem to behave the same on different machines. I posted a day or two ago on this with subject "Mac OS X and missing data". Would love to hear if there is a solution to this :) From tjarvi at qbang.org Sat Mar 3 10:54:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 10:54:17 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > Hi, > > Under > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable > USB -> serial converter(using virtual com port drivers), with using example > code pretty much straight out of > http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port > opens fine, enumerations all work, etc. > > My application calls for a large amount of data to be transferred in a short > amount of time at 2,000,000 baud. My hardware sends approximately 15,232 > bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL > converter work fine, and the application works using C++. > > In C++, I do a > > hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, > OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); > > to open the port, and a > > boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); > > to read the port. > > The variable buffer fills with the 15238 bytes, and returns. > > If I do a > > resultz = is.read(cbuf,0,15238); in java with RXTX > > where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > > and where resultz is an int, and cbuf is a char [] cbuf, resultz gets > EXACTLY 3968 bytes the first time called. If I call it multiple times, I get > roughly 11k total(less than what is sent), never more than the 3968 bytes > per is.read() call. > > My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 > bytes. > > I've played with inputbuffersize, receive threshold, receivetimeout, and so > on. The FTDI virtual com port drivers that I'm using are rock solid, and > have had zero problems with them using a variety of applications, some of my > own, some professionally written, etc. No flow control is used anyplace, no > RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. > > No exceptions are being thrown. > > What am I doing wrong, and what I can adjust to receive the full 15k bytes > in one single read? > > Thanks! > Hi Keith I would expect a 20 meg application is going to have different behavior with the OS than a smaller application with respect to the kernel memory managment, schedualing, ... Something subtle could be causing problems. With respect to the recieve timeout and threshold, if you set the timeout to zero and the threshold to the size of data you expect, read should not return until it get that data. You may try with a stand alone application that tests just that with the C/C++ API. If the read is returning with less data when tested for short reads, you have found a bug in the device driver more than likely. The USB dongle vendor would probably be interested in knowing about this. As mentioned, these devices are getting very good; almost bug free. I suspect you found a bug though if you did use the threshold and timeout properly. The missing data is typical when not using flow control. When the OS buffering fills, the hardware will start dropping bytes. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:38:52 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:38:52 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> update: I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now instead of 3968. This makes sense. 128 bytes of overhead + 3968 bytes of data = 4096 transfer size 32 bytes of overhead + 992 bytes of data = 1024 transfer size. 1/4 the data = 1/4 the overhead. I rearranged my reading like so: resultz = is.read(cbuf,0,3968); resultz = is.read(cbuf,3968,3968); resultz = is.read(cbuf,7936,3968); while (!(is.ready())); // wait for ready resultz = is.read(cbuf,11904,3334); and this grabs 15,238 bytes total. BUT, I still have the quandry of the screwed up multi-bytes. I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. Approx 8% of the data. The bad bytes always seem to take the flavor of 0x2018, 0x2019, x2022, x2030, x201d. Are these maybe errors and I don't know what they enumerate to? I still can't believe some other layer isn't handling putting those bytes together all in one stream for me. Thanks Keith ----- Original Message ----- From: "Keith" To: "Bob Jacobsen" ; "RXTX Developers and Users" Sent: Saturday, March 03, 2007 11:26 AM Subject: Re: [Rxtx] is.read() only returning 3968 bytes > Bob, > > > Interesting numerical coincidence is that (max USB transfer) - (what > > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > > needed to transfer that much data. > > I was thinking along the same lines. I don't know USB well, but I do know > that those numbers were close enough to warrant investigating the > relationship between them. > > > I think what you're seeing is the internal buffering of the USB data > > stream. You'll need some form of higher-level buffering to smooth > > that out. > > Shouldn't the InputStreamReader() and BufferedReader() provide this type of > buffering? Isn't that the idea behind those? > > > All hypotheses need to be tested. In this case, a test would be to > > check for missing data. If this idea is right, you'll get _all_ the > > data, but you won't be missing characters. > > I did start looking at the data. -- I'm getting weird results. > > I tried this: > > loopzz = 0; > > for (looptwo = 0; looptwo < 100000; looptwo++) { > while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > > }} > > So I'm reading one character at a time. The good news is that loopzz is > exactly 15238 at the end of the routine, which is perfectly correct. I > picked looptwo value out of thin air. > > The weird results come in terms of the values, the data isn't correct at > least in one case. Look here: > > 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > > This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). > But the 0x89 was replaced by 0x2030. Why the heck would the returned value > be 0x2030?? Why is the returned byte completely out of range? Why the > multibyte return? > > From InputStream in the API: > > read > public abstract int read() > throws IOExceptionReads the next byte of data from the > input stream. The value byte is returned as an int in the range 0 to 255. If > no byte is available because the end of the stream has been reached, the > value -1 is returned. This method blocks until input data is available, the > end of the stream is detected, or an exception is thrown. > Value should be 0-255. > > > In my application time is really critical, reading 1 byte at a time is > probably not going to work. > > Thanks Eric & Bob for looking at this. > > Keith > From tjarvi at qbang.org Sat Mar 3 12:52:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 12:52:27 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > update: > > I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now > instead of 3968. > > This makes sense. > > 128 bytes of overhead + 3968 bytes of data = 4096 transfer size > 32 bytes of overhead + 992 bytes of data = 1024 transfer size. > > 1/4 the data = 1/4 the overhead. > > I rearranged my reading like so: > > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. > Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? > > I still can't believe some other layer isn't handling putting those bytes > together all in one stream for me. > The layer for this in Serial land is flow control. Software and hardware flow control prevent the overruns you observe. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:54:41 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:54:41 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <001a01c75dcd$c8802a70$6600a8c0@jbh757ktruws7g> Trent, Thanks for taking the time to reply. > I would expect a 20 meg application is going to have different behavior > with the OS than a smaller application with respect to the kernel memory > managment, schedualing, ... Something subtle could be causing problems. Well, at least I know the VCP drivers, the OS, etc can handle 2mbps reliably. Without hiccuping or dropping bytes. The C++ code works reliably without flow control. > The missing data is typical when not using flow control. When the OS > buffering fills, the hardware will start dropping bytes. I'm actually not getting MISSING data, I'm getting CORRUPTED data. If you look at my most recent post, I'm getting these bad bytes in place of the correct values: 0x2018, 0x2019, x2022, x2030, x201d. Why would is.read() return values not in the range of 0-255 ? Thanks. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 08:59:14 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 07:59:14 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: At 1:19 AM -0500 3/3/07, Keith wrote: >If I do a > >resultz = is.read(cbuf,0,15238); in java with RXTX > >where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > >and where resultz is an int, and cbuf is a char [] cbuf, resultz gets >EXACTLY 3968 bytes the first time called. If I call it multiple times, I get >roughly 11k total(less than what is sent), never more than the 3968 bytes >per is.read() call. > >My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 >bytes. Interesting numerical coincidence is that (max USB transfer) - (what you get) = 4096-3968 = 128 bytes is (almost) the size of the headers needed to transfer that much data. I think what you're seeing is the internal buffering of the USB data stream. You'll need some form of higher-level buffering to smooth that out. All hypotheses need to be tested. In this case, a test would be to check for missing data. If this idea is right, you'll get _all_ the data, but you won't be missing characters. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 09:26:14 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 11:26:14 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Bob, > Interesting numerical coincidence is that (max USB transfer) - (what > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > needed to transfer that much data. I was thinking along the same lines. I don't know USB well, but I do know that those numbers were close enough to warrant investigating the relationship between them. > I think what you're seeing is the internal buffering of the USB data > stream. You'll need some form of higher-level buffering to smooth > that out. Shouldn't the InputStreamReader() and BufferedReader() provide this type of buffering? Isn't that the idea behind those? > All hypotheses need to be tested. In this case, a test would be to > check for missing data. If this idea is right, you'll get _all_ the > data, but you won't be missing characters. I did start looking at the data. -- I'm getting weird results. I tried this: loopzz = 0; for (looptwo = 0; looptwo < 100000; looptwo++) { while (is.ready()) { cbuf[loopzz] = (char) is.read(); loopzz++; }} So I'm reading one character at a time. The good news is that loopzz is exactly 15238 at the end of the routine, which is perfectly correct. I picked looptwo value out of thin air. The weird results come in terms of the values, the data isn't correct at least in one case. Look here: 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). But the 0x89 was replaced by 0x2030. Why the heck would the returned value be 0x2030?? Why is the returned byte completely out of range? Why the multibyte return? >From InputStream in the API: read public abstract int read() throws IOExceptionReads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown. Value should be 0-255. In my application time is really critical, reading 1 byte at a time is probably not going to work. Thanks Eric & Bob for looking at this. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 14:44:50 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 13:44:50 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: Java's "char" type is Unicode. I think what you're seeing is a bug in the byte -> Unicode translation. 0x2018, 0x2019 are the curly open and close quotes. There used to be (and might still be) bugs in the conversion of these in a couple of libc versions. Some of the ASCII -> ISO and ISO -> ASCII routines were a little over-ambitious with respect to handling the open and close quotes, and tried to convert them to the "curly" form inappropriately. Try _not_ casting it to char. Bob At 11:26 AM -0500 3/3/07, Keith wrote: >Bob, > >> Interesting numerical coincidence is that (max USB transfer) - (what >> you get) = 4096-3968 = 128 bytes is (almost) the size of the headers >> needed to transfer that much data. > >I was thinking along the same lines. I don't know USB well, but I do know >that those numbers were close enough to warrant investigating the >relationship between them. > >> I think what you're seeing is the internal buffering of the USB data >> stream. You'll need some form of higher-level buffering to smooth >> that out. > >Shouldn't the InputStreamReader() and BufferedReader() provide this type of >buffering? Isn't that the idea behind those? > >> All hypotheses need to be tested. In this case, a test would be to >> check for missing data. If this idea is right, you'll get _all_ the >> data, but you won't be missing characters. > >I did start looking at the data. -- I'm getting weird results. > >I tried this: > >loopzz = 0; > >for (looptwo = 0; looptwo < 100000; looptwo++) { >while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > >}} > >So I'm reading one character at a time. The good news is that loopzz is >exactly 15238 at the end of the routine, which is perfectly correct. I >picked looptwo value out of thin air. > >The weird results come in terms of the values, the data isn't correct at >least in one case. Look here: > >0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > >This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). >But the 0x89 was replaced by 0x2030. Why the heck would the returned value >be 0x2030?? Why is the returned byte completely out of range? Why the >multibyte return? > >>From InputStream in the API: > >read >public abstract int read() > throws IOExceptionReads the next byte of data from the >input stream. The value byte is returned as an int in the range 0 to 255. If >no byte is available because the end of the stream has been reached, the >value -1 is returned. This method blocks until input data is available, the >end of the stream is detected, or an exception is thrown. >Value should be 0-255. > > >In my application time is really critical, reading 1 byte at a time is >probably not going to work. > >Thanks Eric & Bob for looking at this. > >Keith > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 15:10:11 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 17:10:11 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Bob said ..... > Java's "char" type is Unicode. I think what you're seeing is a bug > in the byte -> Unicode translation. Bob -- I think you hit the nail on the head. I was just coming to the same realization here. I knew that something funny was going on because the same bytes always got "corrupted." I'm pretty sure its in the InputStreamReader() functionality where the conversion junk is happening. Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. I don't know if simply changing the cast is going to work. Since the conversion is happening upstream (pun intended), I don't think my cast is doing this. Also I think the compiler forced me to use the cast. I'm still playing around, and I'll report back once I nail it down. Thanks!! Keith From tjarvi at qbang.org Sat Mar 3 15:59:46 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 15:59:46 -0700 (MST) Subject: [Rxtx] Win64 rxtx Testers? Message-ID: I have compiled win64 binaries of rxtx. Are there any users interested in testing them? If so, I'll look into putting them on the web site. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Mar 3 15:35:06 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 14:35:06 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: Because of this and similar problems, JMRI does all it's serial IO using +only+ byte values. It's a but of a pain, as Java wants to go to char and int types a little too aggressively, but it does solve the "uncontrolled conversions" problems. Bob At 5:10 PM -0500 3/3/07, Keith wrote: >Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > >Bob -- I think you hit the nail on the head. > >I was just coming to the same realization here. I knew that something funny >was going on because the same bytes always got "corrupted." > >I'm pretty sure its in the InputStreamReader() functionality where the >conversion junk is happening. > >Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > >I don't know if simply changing the cast is going to work. Since the >conversion is happening upstream (pun intended), I don't think my cast is >doing this. Also I think the compiler forced me to use the cast. -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mark at mdsh.com Sun Mar 4 11:01:33 2007 From: mark at mdsh.com (Mark Himsley) Date: Sun, 04 Mar 2007 18:01:33 +0000 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: <5C01AC72C200388815C04982@bedroom.mdsh.local> On 03 March 2007 14:38 -0500 Keith wrote: > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT > consistent. Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? It looks like you need to use DataInputStream and DataOutputStream. -- Mark Himsley From tjarvi at qbang.org Sun Mar 4 11:35:08 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 11:35:08 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" > > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > > * Line #21 - Not sure if you need a (TM) mark for > the term "Sun" > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > OK. I'm going through this today. Some groups ask if rxtx could be under their license also. I think this is a good example of why I resist multiple licenses and focus on why the current license may not be usable by them. The RXTX project is a convergence of hobby and commercial interests. I happen to do both right now. The problem with licensing is we have to stay on top of them as they change. Clearly, adding more licenses will not make this easier. I'm acting as the hobby person today. RXTX always favors the hobby people. But as we move forward, I'm going to need to bring this to lawyers at work and explain to them what is going on. Others here may have to do this also. I don't anticipate problems or unexpected changes. The goal is a consistant, comprehendable and usable license as close to what we have now as possible. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 14:52:10 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 14:52:10 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (1/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: I'm breaking this into two parts. I expect the second part will need more attention. Comments first, then the changed material below. On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > Thanks > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. OK. RXTX for consitent use. java should not be capitalized because it does not only mean Sun [TM] Java [TM]. An example of this not meaning Java is when people use RXTX with GCJ. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". There are not any contributors that are in all of RXTX yet but I did update the comment to try to reflect the current situation without making it a nightmare to maintain. I looked to see how the Linux kernel does it as a reference point. > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" The URL can be problematic. I have done so below with a time reference. GNU does not provide version information in their URLS. I picture this being a problem when the version 3 comes out. > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > This will be corrected when the copy is updated to the version linked below. ---------------- begin proposed material involved -------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. ----------------- end proposed material involved -------------------- I'll be looking at the linking issue again next. That should be all that remains other than including the 2.1 version. Let me know if you have problems with anything here. I do not want to dilute the material I post next with these housekeeping tasks. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 16:08:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 16:08:36 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: For those that are wondering what is going on here, this next bit is the meat of the changes. We agreed a long time ago to put this disclaimer in. We did a so so job. It was in rxtx 2.0, not well written, ... So some groups using rxtx that would like to ship rxtx so users don't need to download, install, go to the mail-list to find why it failed, ... Then their legal teams tell them section 5 paragraph 2 is a show stopper. That was never the intent. Now going through what remains... > and might need a (TM) suffix to make Sun happy. Added disclaimer at the ended 'all trademarks belong...' > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. OK. As you can see I was trying to adjust GNU text there for the LGPL. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. used dynamically linked terminology. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". I tried to address this more upfront with an intent statement. Let me know if you have problems with it. I also tried to make it a little more clear what was derived from the GNU solution by moving the link location closer to GNU's suggestion. > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > Thats the intent. Here is the combined fixes. Note that only the material in /*-- --*/ is being touched. The new GPL license is there but unmodified. ------------------------ begin proposed new license ------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. | | An executable that contains no derivative of any portion of RXTX, but | is designed to work with RXTX by being dynamically linked with it, | is considered a "work that uses the Library" subject to the terms and | conditions of the GNU Lesser General Public License. | | The following has been added to the RXTX License to remove | any confusion about linking to RXTX. We want to allow in part what | section 5, paragraph 2 of the LGPL does not permit in the special | case of linking over a controlled interface. The intent is to add a | Java Specification Request or standards body defined interface in the | future as another exception but one is not currently available. | | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface | | As a special exception, the copyright holders of RXTX give you | permission to link RXTX with independent modules that communicate with | RXTX solely through the Sun Microsytems CommAPI interface version 2, | regardless of the license terms of these independent modules, and to copy | and distribute the resulting combined work under terms of your choice, | provided that every copy of the combined work is accompanied by a complete | copy of the source code of RXTX (the version of RXTX used to produce the | combined work), being distributed under the terms of the GNU Lesser General | Public License plus this exception. An independent module is a | module which is not derived from or based on RXTX. | | Note that people who make modified versions of RXTX are not obligated | to grant this special exception for their modified versions; it is | their choice whether to do so. The GNU Lesser General Public License | gives permission to release a modified version without this exception; this | exception also makes it possible to release a modified version which | carries forward this exception. | | You should have received a copy of the GNU Lesser General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA | All trademarks belong to their respective owners. --------------------------------------------------------------------------*/ The original GNU Lesser General Public License Follows. GNU LESSER GENERAL PUBLIC LICENSE Version 2.1, February 1999 Copyright (C) 1991, 1999 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. [This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence the version number 2.1.] Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This license, the Lesser General Public License, applies to some specially designated software packages--typically libraries--of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below. When we speak of free software, we are referring to freedom of use, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish); that you receive source code or can get it if you want it; that you can change the software and use pieces of it in new free programs; and that you are informed that you can do these things. To protect your rights, we need to make restrictions that forbid distributors to deny you these rights or to ask you to surrender these rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library or if you modify it. For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights. We protect your rights with a two-step method: (1) we copyright the library, and (2) we offer you this license, which gives you legal permission to copy, distribute and/or modify the library. To protect each distributor, we want to make it very clear that there is no warranty for the free library. Also, if the library is modified by someone else and passed on, the recipients should know that what they have is not the original version, so that the original author's reputation will not be affected by problems that might be introduced by others. Finally, software patents pose a constant threat to the existence of any free program. We wish to make sure that a company cannot effectively restrict the users of a free program by obtaining a restrictive license from a patent holder. Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license. Most GNU software, including some libraries, is covered by the ordinary GNU General Public License. This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs. When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library. We call this license the "Lesser" General Public License because it does Less to protect the user's freedom than the ordinary General Public License. It also provides other free software developers Less of an advantage over competing non-free programs. These disadvantages are the reason we use the ordinary General Public License for many libraries. However, the Lesser license provides advantages in certain special circumstances. For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License. In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software. For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU operating system, as well as its variant, the GNU/Linux operating system. Although the Lesser General Public License is Less protective of the users' freedom, it does ensure that the user of a program that is linked with the Library has the freedom and the wherewithal to run that program using a modified version of the Library. The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, whereas the latter must be combined with the library in order to run. GNU LESSER GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License Agreement applies to any software library or other program which contains a notice placed by the copyright holder or other authorized party saying it may be distributed under the terms of this Lesser General Public License (also called "this License"). Each licensee is addressed as "you". A "library" means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables. The "Library", below, refers to any such software library or work which has been distributed under these terms. A "work based on the Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term "modification".) "Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library. Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does. 1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) The modified work must itself be a software library. b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change. c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License. d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful. (For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library. In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. 4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange. If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code. 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables. When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law. If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.) Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself. 6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications. You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things: a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.) b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. c) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution. d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place. e) Verify that the user has already received a copy of these materials or that you have already sent this user a copy. For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute. 7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things: a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above. b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work. 8. You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 9. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Library (or any work based on the Library), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Library or works based on it. 10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties with this License. 11. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply, and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 12. If the distribution and/or use of the Library is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Library under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 13. The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation. 14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Libraries If you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the ordinary General Public License). To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Also add information on how to contact you by electronic and paper mail. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the library, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the library `Frob' (a library for tweaking knobs) written by James Random Hacker. , 1 April 1990 Ty Coon, President of Vice That's all there is to it! ------------------------ end of proposed license ------------------ -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sun Mar 4 16:26:04 2007 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 04 Mar 2007 17:26:04 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <45EB558C.3010609@cox.net> Bob Jacobsen wrote: > Because of this and similar problems, JMRI does all it's serial IO > using +only+ byte values. It's a but of a pain, as Java wants to go > to char and int types a little too aggressively, but it does solve > the "uncontrolled conversions" problems. Anytime that you are reading bytes of data that is not printable, unicode text, in Java, you really need to stay away from the Readers. Use input stream only, or you will see unicode valued byte groups converted to unicode "char" values. Gregg Wonderly From joachim at buechse.de Mon Mar 5 04:23:48 2007 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 5 Mar 2007 12:23:48 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> The behaviour is exactly what you asked for in you code. is = new BufferedReader(new InputStreamReader(port.getInputStream())); Readers return Text (ie unicode chars) not bytes. You instantiate the InputStreamReader without saying which charset you want, which means "platform default". As this is on Windows, it will convert Windows characters to equivalent unicode characters. If you want to read bytes, read bytes not Text. Reading bytes is done with InputStream and BufferedInputStream. BTW: The InputStream and Reader methods that read arrays are not guarenteed to fill up the array. You always have to check what you really got, and advance your index accordingly. A typical "read up to 32k" method looks like this: InputStream is= ... // -- determine the max buffer size int len= is.available(); if (len == 0) { len= 32 * 1024; } // -- read all available data byte[] buffer= new byte[len]; int pos= 0; int read; do { read= is.read(buffer, pos, buffer.length - pos); pos= pos + read; } while (read != -1 && pos < buffer.length); Best regards, Joachim --- Joachim B?chse Phone: +41 44 500 2604 Buechse Consulting Hadlaubsteig 2 CH-8006 Z?rich On 03.03.2007, at 23:10, Keith wrote: > Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > > Bob -- I think you hit the nail on the head. > > I was just coming to the same realization here. I knew that > something funny > was going on because the same bytes always got "corrupted." > > I'm pretty sure its in the InputStreamReader() functionality where the > conversion junk is happening. > > Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > > I don't know if simply changing the cast is going to work. Since the > conversion is happening upstream (pun intended), I don't think my > cast is > doing this. Also I think the compiler forced me to use the cast. > > I'm still playing around, and I'll report back once I nail it down. > > Thanks!! > > Keith > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Mon Mar 5 07:25:46 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 05 Mar 2007 08:25:46 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> Message-ID: <45EC286A.8060608@cox.net> Joachim Buechse wrote: > BTW: The InputStream and Reader methods that read arrays are not > guarenteed to fill up the array. You always have to check what you > really got, and advance your index accordingly. A typical "read up to > 32k" method looks like this: > > InputStream is= ... > // -- determine the max buffer size > int len= is.available(); > if (len == 0) { > len= 32 * 1024; > } > // -- read all available data > byte[] buffer= new byte[len]; > int pos= 0; > int read; > do { > read= is.read(buffer, pos, buffer.length - pos); > pos= pos + read; > } while (read != -1 && pos < buffer.length); > My preferred structure is. byte arr[ len ]; int cnt; int off = 0; while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { off += cnt; } This keeps you from adding -1 to pos when the read returns -1. It also skips out when the read is 0 bytes which, is not a described EOF in InputStream java docs, but is a condition I want to be aware of. Gregg Wonderly From joachim at buechse.de Tue Mar 6 02:52:58 2007 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 6 Mar 2007 10:52:58 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <45EC286A.8060608@cox.net> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: The code I copied was from a file resource reader, it shouldn't really be applied to networking/external IO code. Mea culpa. However aborting when you get 0 from read is not always what you want either (you kind of indicated that already). Some unix java implementations will return 0 if the kernel read was aborted with EINTER, which is rarely the point where you want to abort your read - at least not without further checks. A "complete" solution always depends on the events you need to handle and the time the total read could take in reality. In some cases it's worth checking Thread.isInterrupted() in the loop, some code re-loops on 0 but only a limited number of times, some check a total timeout limit, etc... Best regards, Joachim On 05.03.2007, at 15:25, Gregg Wonderly wrote: > My preferred structure is. > > byte arr[ len ]; > int cnt; > int off = 0; > while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { > off += cnt; > } > > This keeps you from adding -1 to pos when the read returns -1. It > also skips > out when the read is 0 bytes which, is not a described EOF in > InputStream java > docs, but is a condition I want to be aware of. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Mar 6 14:47:44 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 Mar 2007 14:47:44 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: Just FYI, rxtx will usually not break out on EINTER. The code in the native library usually does something close to this: do { read(...) } while ( !done && errno==EINTR ); Obviously there is a little more involved but it will retry on EINTER if not done. On Tue, 6 Mar 2007, Joachim Buechse wrote: > The code I copied was from a file resource reader, it shouldn't > really be applied to networking/external IO code. Mea culpa. > > However aborting when you get 0 from read is not always what you want > either (you kind of indicated that already). Some unix java > implementations will return 0 if the kernel read was aborted with > EINTER, which is rarely the point where you want to abort your read - > at least not without further checks. A "complete" solution always > depends on the events you need to handle and the time the total read > could take in reality. In some cases it's worth checking > Thread.isInterrupted() in the loop, some code re-loops on 0 but only > a limited number of times, some check a total timeout limit, etc... > > Best regards, > Joachim > > On 05.03.2007, at 15:25, Gregg Wonderly wrote: >> My preferred structure is. >> >> byte arr[ len ]; >> int cnt; >> int off = 0; >> while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { >> off += cnt; >> } >> >> This keeps you from adding -1 to pos when the read returns -1. It >> also skips >> out when the read is 0 bytes which, is not a described EOF in >> InputStream java >> docs, but is a condition I want to be aware of. >> >> Gregg Wonderly >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 gjhanna at gmail.com Thu Mar 8 13:42:52 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Fri, 9 Mar 2007 09:42:52 +1300 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? Message-ID: I've just struck an issue using rxtx in a multi-threaded environment: If I have 3 threads trying to open *the same* comm-port I get a deadlock in CommPortIdentifier.open If I have just 2, it works fine - I get a PortInUseException which is nice and I can handle it. The 3 thread->deadlock thing is causing me issues. (Sample code below). This is from the java thread-dump Found one Java-level deadlock: ============================= "Thread-2": waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object ), which is held by "Thread-1" "Thread-1": waiting to lock monitor 0x0003e9cc (object 0x2450e108, a gnu.io.CommPortIdentifier), which is held by "Thread-2" Java stack information for the threads listed above: =================================================== "Thread-2": at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:329) - waiting to lock <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) "Thread-1": at java.lang.Object.wait(Native Method) - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) - locked <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) (Apart from this, rxtx is working fantastically for us). I'm thinking I'll have to implement some sort of locking mechanism that *doesn't* use java synchronization to prevent this situation. (Which doesn't sound like a good idea to me). Any ideas? Thanks, Greg Hanna ============= RXTXLockTest.java ======================================== import gnu.io.CommPort; import gnu.io.CommPortIdentifier; /** * @author Greg Hanna * Minimal code to create a deadlock with rxtx in multithreaded open */ public class RXTXLockTest { public static void main(String[] args) { try { CommPortIdentifier cpiCom1 = CommPortIdentifier.getPortIdentifier ("COM14"); OpenThread t1 = new OpenThread (" one ", cpiCom1); OpenThread t2 = new OpenThread (" two ", cpiCom1); OpenThread t3 = new OpenThread (" 003 ", cpiCom1); t1.start(); t2.start(); t3.start(); // comment this out and it runs with (expected) PortInUseException } catch (Exception e) { e.printStackTrace(); } } } class OpenThread extends Thread { String name; CommPortIdentifier cpi; CommPort cp; public OpenThread (String name, CommPortIdentifier cpi) { this.name = name; this.cpi = cpi; System.out.println (System.currentTimeMillis() + name + " thread created"); } public void run () { try { System.out.println (System.currentTimeMillis() + name + " opening"); cp = cpi.open(name, 2000); System.out.println (System.currentTimeMillis() + name + " opened - sleeping"); sleep (2000); // do the serial comms with the device. System.out.println (System.currentTimeMillis() + name + " slept - closing"); cp.close(); System.out.println (System.currentTimeMillis() + name + " closed - exiting"); } catch (Exception e) { System.out.println ("Error in thread: " + name ); e.printStackTrace(); } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070308/d9a163c5/attachment-0008.html From eu259473 at tele2.it Fri Mar 9 02:46:20 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 09 Mar 2007 10:46:20 +0100 Subject: [Rxtx] rxtx: tru64 unix make fails Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070309/3b654523/attachment-0008.html From lyon at docjava.com Fri Mar 9 03:58:32 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 Mar 2007 05:58:32 -0500 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi All, The deadlock issue is one that I have been thinking about for some time now. It seems to me that we need a resource manager that enables assignment to a known process. The one thing that seems important about serial ports is that two applications should not use the same serial port at the same time. When this happens, it throws an exception. OK. The exception is a response to a lock condition that arises from an unavailable resource. An abstract implementation (not born of native methods) might assign a serial port to an application, until the application releases it (or is forced to release it by some kill mechanism). Some resources (like a registry) can be reused. But others, like the serial port, cannot. In the case of the serial port, we would like, I think, to have the flyweight design pattern without sharing and with object assignment tracking. A means of breaking deadlock (like a leasing mechanism) seems very useful, to me. My guess is that we can serialize the state of the Parametric Singleton Pattern (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) into the Preferences of the System. Preferences.systemRoot() might help with that. When a resource is checked out, the lease time and owner are listed. A thread that does this can be killed, but applications outside of Java are problematic. There is a compelling problem here. It is not just serial ports. Sound cards, cameras, microphones, files, tape drives, etc. All are consumed resources that are assigned to an application (or user) and deprive other applications, or users, from use. What, if anything, should we do? At present we throw PortInUseExceptions. Is that it? Can we do better? OK, the port is in use. Now what? Do I have to be root to go remove lock files and kill applications? Is there a better way? Thanks! - Doug >I've just struck an issue using rxtx in a multi-threaded environment: > >If I have 3 threads trying to open *the same* >comm-port I get a deadlock in >CommPortIdentifier.open >If I have just 2, it works fine - I get a >PortInUseException which is nice and I can >handle it. > >The 3 thread->deadlock thing is causing me issues. >(Sample code below). > >This is from the java thread-dump > >Found one Java-level deadlock: >============================= >"Thread-2": > waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), > which is held by "Thread-1" >"Thread-1": > waiting to lock monitor 0x0003e9cc (object >0x2450e108, a gnu.io.CommPortIdentifier ), > which is held by "Thread-2" > >Java stack information for the threads listed above: >=================================================== >"Thread-2": > at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) > - waiting to lock <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) >"Thread-1": > at java.lang.Object.wait(Native Method) > - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) > - locked <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) > > >(Apart from this, rxtx is working fantastically for us). > >I'm thinking I'll have to implement some sort of >locking mechanism that *doesn't* use java >synchronization to prevent this situation. >(Which doesn't sound like a good idea to me). > >Any ideas? > >Thanks, > >Greg Hanna > >============= RXTXLockTest.java ======================================== > >import gnu.io.CommPort; >import gnu.io.CommPortIdentifier; > >/** > * @author Greg Hanna > * Minimal code to create a deadlock with rxtx in multithreaded open > */ >public class RXTXLockTest { > ? > ?public static void main(String[] args) { > ?try { > ?CommPortIdentifier cpiCom1 = >CommPortIdentifier.getPortIdentifier ("COM14"); > ?OpenThread t1 = new OpenThread (" one ", cpiCom1); > ?OpenThread t2 = new OpenThread (" two ", cpiCom1); > ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); > ?t1.start(); > ?t2.start(); > ?t3.start(); // comment this out >and it runs with (expected) PortInUseException > ?} catch (Exception e) { > ?e.printStackTrace(); > ?} > ?} >} > >class OpenThread extends Thread { > ?String name; > ?CommPortIdentifier cpi; > ?CommPort cp; > ?public OpenThread (String name, CommPortIdentifier cpi) { > ? this.name = name; > ?this.cpi = cpi; > ?System.out.println >(System.currentTimeMillis() + name + " thread >created"); > ?} > ?public void run () { > ?try { > ?System.out.println >(System.currentTimeMillis() + name + " opening"); > ?cp = cpi.open(name, 2000); > ?System.out.println >(System.currentTimeMillis() + name + " opened - >sleeping"); > ?sleep (2000); // do the serial comms with the device. > ?System.out.println >(System.currentTimeMillis() + name + " slept - >closing"); > ?cp.close(); > ?System.out.println >(System.currentTimeMillis() + name + " closed - >exiting"); > ?} catch (Exception e) { > System.out.println ("Error in thread: " + name ); > ?e.printStackTrace(); > ?} > ?} >} > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Mar 9 06:37:45 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 Mar 2007 06:37:45 -0700 (MST) Subject: [Rxtx] rxtx: tru64 unix make fails In-Reply-To: References: Message-ID: On Fri, 9 Mar 2007, "Giuseppe Marchese" wrote: > Sorry for delay. > ? > This is log for ./configure and make > error. > ? > thanks for attention > ? > Make: '%.java,$(TOP)/$(CLASSDEST)/%.class,$(wildcard $(SPATH)/*.java)': extra chars.? > Stop. > Hi Giuseppe You need to use GNU make with the Makefile. I suspect the tru64 make is not happy with those rules. > configure: exit 0 Looks like configure is fairly happy. From tjarvi at qbang.org Sat Mar 10 07:43:51 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 07:43:51 -0700 (MST) Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi Doug I have very little time to look into this further but what we could do is open up an rxtx 3 devel branch in which a proof of concept could be worked on. It could be the proof of concept for a JSR others including Sun could look at/work on or parts of it could be recycled in a JSR. I'm working very hard on rxtx right now but it does not show. I'm looking at win64, mac intel/ppc, usb bluetooth and usb serial dongles. Some are going to be more tested than others but they are all on the plate. I'll be pushing all the fixes upstream when they are done. So I'm very busy in 2.1 but we could open a new branch. On Fri, 9 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > The deadlock issue is one that I have been thinking about > for some time now. > It seems to me that we need a resource manager that enables assignment > to a known process. > > The one thing that seems important about serial > ports is that two applications should not use the > same serial port at the same time. When this > happens, it throws an exception. > OK. > > The exception is a response to a lock condition that > arises from an unavailable resource. > > An abstract implementation (not born of native methods) might > assign a serial port to an application, until the > application releases it (or is forced to release > it by some kill mechanism). > > Some resources (like a registry) can be reused. > But others, like the serial port, > cannot. > > In the case of the serial port, we would like, I think, to > have the flyweight design pattern > without sharing and with object assignment tracking. > A means of breaking deadlock (like a leasing > mechanism) seems very useful, to me. > > My guess is that we can serialize the state of the Parametric Singleton Pattern > (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) > into the Preferences of the System. Preferences.systemRoot() might help > with that. When a resource is checked out, the lease time and owner are > listed. A thread that does this can be killed, but applications outside of Java > are problematic. > > There is a compelling problem here. It is not just serial ports. > Sound cards, cameras, microphones, files, tape drives, etc. All are consumed > resources that are assigned to an application (or > user) and deprive other applications, > or users, from use. > > What, if anything, should we do? At present we throw PortInUseExceptions. > Is that it? > Can we do better? > OK, the port is in use. Now what? > Do I have to be root to go remove lock files and kill applications? > Is there a better way? > > Thanks! > - Doug > >> I've just struck an issue using rxtx in a multi-threaded environment: >> >> If I have 3 threads trying to open *the same* >> comm-port I get a deadlock in >> CommPortIdentifier.open >> If I have just 2, it works fine - I get a >> PortInUseException which is nice and I can >> handle it. >> >> The 3 thread->deadlock thing is causing me issues. >> (Sample code below). >> >> This is from the java thread-dump >> >> Found one Java-level deadlock: >> ============================= >> "Thread-2": >> waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), >> which is held by "Thread-1" >> "Thread-1": >> waiting to lock monitor 0x0003e9cc (object >> 0x2450e108, a gnu.io.CommPortIdentifier ), >> which is held by "Thread-2" >> >> Java stack information for the threads listed above: >> =================================================== >> "Thread-2": >> at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) >> - waiting to lock <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> "Thread-1": >> at java.lang.Object.wait(Native Method) >> - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) >> - locked <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> >> >> (Apart from this, rxtx is working fantastically for us). >> >> I'm thinking I'll have to implement some sort of >> locking mechanism that *doesn't* use java >> synchronization to prevent this situation. >> (Which doesn't sound like a good idea to me). >> >> Any ideas? >> >> Thanks, >> >> Greg Hanna >> >> ============= RXTXLockTest.java ======================================== >> >> import gnu.io.CommPort; >> import gnu.io.CommPortIdentifier; >> >> /** >> * @author Greg Hanna >> * Minimal code to create a deadlock with rxtx in multithreaded open >> */ >> public class RXTXLockTest { >> ? >> ?public static void main(String[] args) { >> ?try { >> ?CommPortIdentifier cpiCom1 = >> CommPortIdentifier.getPortIdentifier ("COM14"); >> ?OpenThread t1 = new OpenThread (" one ", cpiCom1); >> ?OpenThread t2 = new OpenThread (" two ", cpiCom1); >> ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); >> ?t1.start(); >> ?t2.start(); >> ?t3.start(); // comment this out >> and it runs with (expected) PortInUseException >> ?} catch (Exception e) { >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> class OpenThread extends Thread { >> ?String name; >> ?CommPortIdentifier cpi; >> ?CommPort cp; >> ?public OpenThread (String name, CommPortIdentifier cpi) { >> ? this.name = name; >> ?this.cpi = cpi; >> ?System.out.println >> (System.currentTimeMillis() + name + " thread >> created"); >> ?} >> ?public void run () { >> ?try { >> ?System.out.println >> (System.currentTimeMillis() + name + " opening"); >> ?cp = cpi.open(name, 2000); >> ?System.out.println >> (System.currentTimeMillis() + name + " opened - >> sleeping"); >> ?sleep (2000); // do the serial comms with the device. >> ?System.out.println >> (System.currentTimeMillis() + name + " slept - >> closing"); >> ?cp.close(); >> ?System.out.println >> (System.currentTimeMillis() + name + " closed - >> exiting"); >> ?} catch (Exception e) { >> System.out.println ("Error in thread: " + name ); >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 mm at UDel.Edu Sat Mar 10 14:48:32 2007 From: mm at UDel.Edu (Mike Markowski) Date: Sat, 10 Mar 2007 16:48:32 -0500 Subject: [Rxtx] rxtx and Sun's comm api Message-ID: <45F327B0.2060004@udel.edu> Hi all, I joined the list a few days ago and apologize for what is likely a frequently asked question, though I haven't yet found it anywhere. I learned about rxtx.org through the readme on Sun's version 2 of their comms api. They give recommendations in that readme regarding how a better comms api should be written. Is this the aim of rxtx.org? I wrote an app on my linux box using the Sun comms api (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the fact that only linux and Solaris are supported. So I'm glad to find rxtx.org and am just reading up on how make the conversion so Windows users will be able to run the program as well. At the same time I'm just curious if rxtx.org and Sun are both heading in the same direction. Thanks for any background or historical info. Feel free to point me to any www pages if my googling has just completely missed the target! Thanks again, Mike From tjarvi at qbang.org Sat Mar 10 15:35:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 15:35:25 -0700 (MST) Subject: [Rxtx] rxtx and Sun's comm api In-Reply-To: <45F327B0.2060004@udel.edu> References: <45F327B0.2060004@udel.edu> Message-ID: On Sat, 10 Mar 2007, Mike Markowski wrote: > Hi all, > > I joined the list a few days ago and apologize for what is likely a > frequently asked question, though I haven't yet found it anywhere. I > learned about rxtx.org through the readme on Sun's version 2 of their > comms api. They give recommendations in that readme regarding how a > better comms api should be written. Is this the aim of rxtx.org? > > I wrote an app on my linux box using the Sun comms api > (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the > fact that only linux and Solaris are supported. So I'm glad to find > rxtx.org and am just reading up on how make the conversion so Windows > users will be able to run the program as well. At the same time I'm > just curious if rxtx.org and Sun are both heading in the same direction. > > Thanks for any background or historical info. Feel free to point me to > any www pages if my googling has just completely missed the target! > I do not have any news (good or bad) concerning RXTX and Sun working together but perhaps others here do. The main goal of RXTX is to expose POSIX termios interfaces to java users. The future support of javax.comm is questionable. We do not have resources for everything. gnu.io (RXTX 2.1) will be supported going forward and functions the same as CommAPI 2.0. If you have control of the source code you are working with, I would not advise using CommAPI 2.0 javax.comm. We do support CommAPI 2.0 javax.comm for older applications but I do not think that will last much longer for practical reasons. The download interest in CommAPI 2.0 javax.comm support is becomming negligible on this end. There has been discussion of a JSR effort but I do not know of any status change since it was mentioned. One problem with a JSR is that even a light weight process is going to be difficult for RXTX at this time. Maybe that will change in the future but then again it may not. For now, we are just going forward 'as is' in rxtx 2.1 with package gnu.io while trying as a secondary effort to backport the changes to rxtx 2.0 for javax.comm support for users that do not have a choice. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Mar 11 07:19:40 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 11 Mar 2007 08:19:40 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: Hi All, I have been a proponent of a JSR that makes use of RXTX. I have executed the proper agreements with Sun. At this point we are in the: Early Draft Review of Draft Specifications Stage. The best thing to do is to enter the quiet period and create a specification. The question of exactly how we, as a group, want to approach this problem, remains open. Typically, we should have both a specification and a reference implementation. Thus, it would be to our best advantage to have a nice, stable, cross platform RXTX distro that adheres to the groups specification. Now, from a specification standpoint, my personal view on the matter is that we create a series of interfaces, with nice documentation (or at least javadoc). Is this a good idea? Should we have a pure interface specification for the communication API? There are several issues, in my mind, which still weigh on us. Hot-pluggable dongles, long discovery process on pop-up ports, lack of uniformity on device names, lack of uniformity on locking, a precise understanding of how the SerialPortResourceManager works (or even if we should have one). The more questions we answer in our reference implementation, the better our specification will get. RXTX is a good working prototype, but, I don't know if that is what we want to use for a specification. Here is what I have for a CommPortInterface: */ public interface CommPortInterface { /** * @return a string representation of this port. */ String toString(); /** * Gets the name of the communications port. This name should correspond to * something the user can identify, like the label on the hardware. * @return name of the port */ String getName(); /** * @return an input stream that can be used to read data from the * communications port. If the port doesn't support reading data, this * method returns null. *

* The blocking behaviour of this input stream depends on the threshold * and timeout values, as shown below for a read buffer size of n * bytes: * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ThresholdTimeoutBlocking behaviour
StateValueStateValue
disableddisabledblock until data is available
enabledm bytesdisabledblock until min(m, n) bytes are available
disabledenabledt msblock for t ms or until data is available
enabledm bytesenabledt msblock for t ms or until min(m, n) bytes are * available
* @throws java.io.IOException */ InputStream getInputStream() throws IOException; /** * @return an output stream that can be used to send data to the * communications port. If the port doesn't support sending data, this * method returns null. * @throws java.io.IOException */ OutputStream getOutputStream() throws IOException; /** * Closes this communications port. * All PortOwnershipListeners will be? * notified of this change of ownership. Further method calls on this? * object will throw IllegalStateException. Further calls on the? * associated InputStream or OutputStream will throw IOException. *

* Close does not block. Undelivered data is discarded. Blocked read and? * write operations are aborted if the underlying operating systems? * supports an IO abort mechanism. To await the delivery of undelivered? * data call OutputStream.flush() or OutputStream.close() before calling? * Port.close(). */ void close(); /** * Enables receive threshold. * When the specified threshold number of bytes are retrieved, read will * return immediately. * * @param thresh the number of bytes in the input buffer * @throws gnu.io.UnsupportedCommOperationException * if receive threshold is * not supported by the driver * @see #disableReceiveThreshold */ void enableReceiveThreshold(int thresh) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive threshold. * * @see #enableReceiveThreshold */ void disableReceiveThreshold(); /** * @return true if receive threshold is enabled. * * @see #enableReceiveThreshold */ boolean isReceiveThresholdEnabled(); /** * @return the receive threshold value. If receive threshold is diabled * or not supported, this value is meaningless. * * @see #enableReceiveThreshold */ int getReceiveThreshold(); /** * Enables receive timeout. * When the specified number of milliseconds have elapsed, read will * return immediately. * * @param rcvTimeout the number of milliseconds to block for * @throws gnu.io.UnsupportedCommOperationException * if receive timeout is * not supported by the driver * @see #disableReceiveTimeout */ void enableReceiveTimeout(int rcvTimeout) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive timeout. * * @see #enableReceiveTimeout */ void disableReceiveTimeout(); /** * @return true if receive timeout is enabled. * * @see #enableReceiveTimeout */ boolean isReceiveTimeoutEnabled(); /** * @return the receive timeout value. If receive timeout is diabled * or not supported, this value is meaningless. * * @see #enableReceiveTimeout */ int getReceiveTimeout(); /** * Enables receive framing. * The supplied byte value in the input suggests the end of the received * frame, and read returns immediately. Only the low 8 bits of the * supplied value are significant. * * @param framingByte the frame delimiter * @throws gnu.io.UnsupportedCommOperationException * if receive framing is * not supported by the driver * @see #disableReceiveFraming */ void enableReceiveFraming(int framingByte) throws UnsupportedCommOperationException; /** * Disables receive framing. * * @see #enableReceiveFraming */ void disableReceiveFraming(); /** * @return true if receive framing is enabled. * * @see #enableReceiveFraming */ boolean isReceiveFramingEnabled(); /** * @return true if receive framing byte. If receive framing is diabled * or not supported, this value is meaningless. * * @see #enableReceiveFraming */ int getReceiveFramingByte(); /** * Sets the input buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setInputBufferSize(int size); /** * @return the input buffer size. * The driver may choose not to report correct values. */ int getInputBufferSize(); /** * Sets the output buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setOutputBufferSize(int size); /** * @return the output buffer size. * The driver may choose not to report correct values. */ int getOutputBufferSize(); } What do you think of that? Note the wishy washy nature of the spec: The driver may choose to ignore this method. Is that good enough for us? Thanks! - Doug From ra85551 at gmail.com Sun Mar 11 08:44:45 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Sun, 11 Mar 2007 17:44:45 +0300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hello, world! I am writing application that communicates with modem via AT commands. My OS is Linux Kubuntu Feisty Herd, to ensure that my application will run properly under Windows XP I installed VMWare server. When I tried to send AT command and evaluate modem answer under WinXP @ VMWare server, I actually didn't receive anything. I think that VM settings are right, because I do can communicate with modem by using standard HyperTerminall as well as I can do on native Windows. So, why RXTX doesn't work under VM, but works under Linux and pure Windows XP (i tested it there) well? The send/receive method code follows. private String sendATCommand(String command, final String waitFor, final boolean isRegex, boolean isAddCRLF, long timeout) throws BeaconConnectException { final long POLL_PERIOD = 100; final int BUFFER_SIZE = 512; final byte[] buffer = new byte[BUFFER_SIZE]; final InputStream serialInput; final OutputStream serialOutput; try { serialInput = serialPort.getInputStream(); if (command != null) { serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } } catch (IOException e) { throw new MyException("serial I/O error"); } TimerTask task = new TimerTask() { int offset = 0; int bytesRead; public synchronized void run() { try { if (serialInput.available() > 0) { bytesRead = serialInput.read(buffer, offset, BUFFER_SIZE - offset); } else { return; } } catch (IOException e) { // do nothing - maybe next time we'll read something } offset += bytesRead; if (waitFor != null) { String temporary = new String(buffer, 0, offset).trim(); if (isRegex && temporary.matches(waitFor) || temporary.contains(waitFor)) { cancel(); notify(); } } } }; Timer timer = new Timer(); timer.schedule(task, POLL_PERIOD, POLL_PERIOD); synchronized (task) { try { task.wait(timeout); task.cancel(); } catch (InterruptedException e) { } } //Cut off leading and trailing CRs, LFs and zeroes String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); System.out.println(response); return response; } -- Pavel Parkhomenko From tjarvi at qbang.org Sun Mar 11 11:48:22 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:48:22 -0600 (MDT) Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: On Sun, 11 Mar 2007, Pavel Parkhomenko wrote: > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. > > private String sendATCommand(String command, final String waitFor, > final boolean isRegex, boolean isAddCRLF, long timeout) > throws BeaconConnectException > { > final long POLL_PERIOD = 100; > final int BUFFER_SIZE = 512; > final byte[] buffer = new byte[BUFFER_SIZE]; > final InputStream serialInput; > final OutputStream serialOutput; > try > { > serialInput = serialPort.getInputStream(); > if (command != null) > { > serialOutput = serialPort.getOutputStream(); > if (isAddCRLF) > { > command += "\r\n"; > } > System.out.println(command); > serialOutput.write(command.getBytes()); > } > } > catch (IOException e) > { > throw new MyException("serial I/O error"); > } > > TimerTask task = new TimerTask() > { > int offset = 0; > int bytesRead; > public synchronized void run() > { > try > { > if (serialInput.available() > 0) > { > bytesRead = serialInput.read(buffer, offset, > BUFFER_SIZE - offset); > } > else > { > return; > } > } > catch (IOException e) > { > // do nothing - maybe next time we'll read something > } > offset += bytesRead; > if (waitFor != null) > { > String temporary = new String(buffer, 0, offset).trim(); > if (isRegex && temporary.matches(waitFor) || > temporary.contains(waitFor)) > { > cancel(); > notify(); > } > } > } > }; > > Timer timer = new Timer(); > timer.schedule(task, POLL_PERIOD, POLL_PERIOD); > synchronized (task) { > try > { > task.wait(timeout); > task.cancel(); > } > catch (InterruptedException e) > { > } > } > //Cut off leading and trailing CRs, LFs and zeroes > String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); > System.out.println(response); > return response; > } > > > Hi Pavel VMWare should not be a problem. I've used it in the past - though not with a modem. Make sure nothing else is using the modem. Then look in the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an example that should work. Note that modems could care less what OS is on top. If you are trying to match new lines to the OS and sending it to the mode for AT commands, thats probably a mistake. Also it would not hurt to print out the individual bytes that you are sending to make sure they did not get mangled along the path. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 11:55:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:55:48 -0600 (MDT) Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: On Sun, 11 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > I have been a proponent of a JSR that makes > use of RXTX. I have executed the proper agreements with Sun. > > At this point we are in the: > Early Draft Review of Draft Specifications Stage. > > The best thing to do is to enter the quiet period and create > a specification. The question of exactly how we, as a group, > want to approach this problem, remains open. > > Typically, we should have both a specification and a reference > implementation. Thus, it would be to our best advantage to have > a nice, stable, cross platform RXTX distro that adheres to the > groups specification. > > Now, from a specification standpoint, my personal view on the matter is > that we create a series of interfaces, with nice documentation (or at least > javadoc). > > Is this a good idea? Should we have a pure interface specification for > the communication API? > > There are several issues, in my mind, which still weigh on us. > Hot-pluggable dongles, long discovery process on pop-up ports, > lack of uniformity on device names, lack of uniformity on locking, > a precise understanding of how the SerialPortResourceManager > works (or even if we should have one). > > The more questions we answer in our reference implementation, the > better our specification will get. RXTX is a good working prototype, > but, I don't know if that is what we want to use for a specification. > > Here is what I have for a CommPortInterface: > */ > public interface CommPortInterface { Hi Doug, I can start going through the method interfaces later this week and giving feedback. I would suggest that the JSR should not be too generic in nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel drivers that intend to look like EIA232 ports at the kernel driver level. some ideas: EIA232PortInterface TermiosInterface SerialPortInterface Something that differentiates this from thing like USB, I2C, ... which should not have to deal with legacy serial claiming to be the comm api. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 12:52:19 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 12:52:19 -0600 (MDT) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: No news is good news with these posts. I'll start the process of pinging legal a week from Monday on my end if nobody has objections to the proposal. I just want to make sure everyone has time to raise objections. Obviously, anyone can fork from a previous version if they don't like the new license. I suspect we can avoid that though. On Sun, 4 Mar 2007, Trent Jarvi wrote: > > For those that are wondering what is going on here, this > next bit is the meat of the changes. We agreed a long time > ago to put this disclaimer in. We did a so so job. It was > in rxtx 2.0, not well written, ... So some groups using > rxtx that would like to ship rxtx so users don't need to > download, install, go to the mail-list to find why it failed, > ... Then their legal teams tell them section 5 paragraph 2 > is a show stopper. > > That was never the intent. > > > Now going through what remains... > >> and might need a (TM) suffix to make Sun happy. > > Added disclaimer at the ended 'all trademarks belong...' > >> * Line #15ff - static vs. dynamic linking - you did >> not transcribe the text from the "controlled >> interface exception" when writing this text - and >> this was good so, because these terms originally >> refer to the GPL rather than the LGPL. I think though, >> that these 4 lines are the most important ones and >> should thus be really really clear. I hope that I >> meet your original intent with the following >> suggestions: >> 1.) Instead of "A program.." it would be better to >> say "An exectuable.." in order to be closer to >> the LGPL text. > > OK. As you can see I was trying to adjust GNU text there > for the LGPL. > >> 2.) It would be better to say .. "by being dynamically >> linked with it" to clearly indicate that dynamic >> linking is meant. The matter of compilation is >> already covered by the LGPL so mentioning it again >> just leads to confusion. > > used dynamically linked terminology. > >> 3.) It would be better to say .. "is considered a >> work that uses the library in contrast to section >> 5 of the LGPL, so the terms of the LGPL do not >> apply to the resulting executable". > > I tried to address this more upfront with an intent statement. > Let me know if you have problems with it. I also tried to > make it a little more clear what was derived from the GNU > solution by moving the link location closer to GNU's suggestion. > >> >> Note that LGPL section 5 says: ..."is called a >> "work that uses the Library". Such a work, in isolation, >> is not a derivative work of the Library, and therefore >> falls outside the scope of this License." >> The next paragraph of the LGPL is exactly the problematic >> one that I hope is clarified by the exception terms you >> give. >> > > Thats the intent. Here is the combined fixes. Note that only the > material in /*-- --*/ is being touched. The new GPL license is > there but unmodified. > > > ------------------------ begin proposed new license ------------------- > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Lesser General Public > | License as published by the Free Software Foundation; either > | version 2.1 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Lesser General Public License for more details. > | > | An executable that contains no derivative of any portion of RXTX, but > | is designed to work with RXTX by being dynamically linked with it, > | is considered a "work that uses the Library" subject to the terms and > | conditions of the GNU Lesser General Public License. > | > | The following has been added to the RXTX License to remove > | any confusion about linking to RXTX. We want to allow in part what > | section 5, paragraph 2 of the LGPL does not permit in the special > | case of linking over a controlled interface. The intent is to add a > | Java Specification Request or standards body defined interface in the > | future as another exception but one is not currently available. > | > | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface > | > | As a special exception, the copyright holders of RXTX give you > | permission to link RXTX with independent modules that communicate with > | RXTX solely through the Sun Microsytems CommAPI interface version 2, > | regardless of the license terms of these independent modules, and to copy > | and distribute the resulting combined work under terms of your choice, > | provided that every copy of the combined work is accompanied by a complete > | copy of the source code of RXTX (the version of RXTX used to produce the > | combined work), being distributed under the terms of the GNU Lesser General > | Public License plus this exception. An independent module is a > | module which is not derived from or based on RXTX. > | > | Note that people who make modified versions of RXTX are not obligated > | to grant this special exception for their modified versions; it is > | their choice whether to do so. The GNU Lesser General Public License > | gives permission to release a modified version without this exception; this > | exception also makes it possible to release a modified version which > | carries forward this exception. > | > | You should have received a copy of the GNU Lesser General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > | All trademarks belong to their respective owners. > --------------------------------------------------------------------------*/ > > The original GNU Lesser General Public License Follows. > > > GNU LESSER GENERAL PUBLIC LICENSE > Version 2.1, February 1999 > > Copyright (C) 1991, 1999 Free Software Foundation, Inc. > 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > Everyone is permitted to copy and distribute verbatim copies > of this license document, but changing it is not allowed. > > [This is the first released version of the Lesser GPL. It also counts > as the successor of the GNU Library Public License, version 2, hence > the version number 2.1.] > > Preamble > > The licenses for most software are designed to take away your > freedom to share and change it. By contrast, the GNU General Public > Licenses are intended to guarantee your freedom to share and change > free software--to make sure the software is free for all its users. > > This license, the Lesser General Public License, applies to some > specially designated software packages--typically libraries--of the > Free Software Foundation and other authors who decide to use it. You > can use it too, but we suggest you first think carefully about whether > this license or the ordinary General Public License is the better > strategy to use in any particular case, based on the explanations below. > > When we speak of free software, we are referring to freedom of use, > not price. Our General Public Licenses are designed to make sure that > you have the freedom to distribute copies of free software (and charge > for this service if you wish); that you receive source code or can get > it if you want it; that you can change the software and use pieces of > it in new free programs; and that you are informed that you can do > these things. > > To protect your rights, we need to make restrictions that forbid > distributors to deny you these rights or to ask you to surrender these > rights. These restrictions translate to certain responsibilities for > you if you distribute copies of the library or if you modify it. > > For example, if you distribute copies of the library, whether gratis > or for a fee, you must give the recipients all the rights that we gave > you. You must make sure that they, too, receive or can get the source > code. If you link other code with the library, you must provide > complete object files to the recipients, so that they can relink them > with the library after making changes to the library and recompiling > it. And you must show them these terms so they know their rights. > > We protect your rights with a two-step method: (1) we copyright the > library, and (2) we offer you this license, which gives you legal > permission to copy, distribute and/or modify the library. > > To protect each distributor, we want to make it very clear that > there is no warranty for the free library. Also, if the library is > modified by someone else and passed on, the recipients should know > that what they have is not the original version, so that the original > author's reputation will not be affected by problems that might be > introduced by others. > > Finally, software patents pose a constant threat to the existence of > any free program. We wish to make sure that a company cannot > effectively restrict the users of a free program by obtaining a > restrictive license from a patent holder. Therefore, we insist that > any patent license obtained for a version of the library must be > consistent with the full freedom of use specified in this license. > > Most GNU software, including some libraries, is covered by the > ordinary GNU General Public License. This license, the GNU Lesser > General Public License, applies to certain designated libraries, and > is quite different from the ordinary General Public License. We use > this license for certain libraries in order to permit linking those > libraries into non-free programs. > > When a program is linked with a library, whether statically or using > a shared library, the combination of the two is legally speaking a > combined work, a derivative of the original library. The ordinary > General Public License therefore permits such linking only if the > entire combination fits its criteria of freedom. The Lesser General > Public License permits more lax criteria for linking other code with > the library. > > We call this license the "Lesser" General Public License because it > does Less to protect the user's freedom than the ordinary General > Public License. It also provides other free software developers Less > of an advantage over competing non-free programs. These disadvantages > are the reason we use the ordinary General Public License for many > libraries. However, the Lesser license provides advantages in certain > special circumstances. > > For example, on rare occasions, there may be a special need to > encourage the widest possible use of a certain library, so that it becomes > a de-facto standard. To achieve this, non-free programs must be > allowed to use the library. A more frequent case is that a free > library does the same job as widely used non-free libraries. In this > case, there is little to gain by limiting the free library to free > software only, so we use the Lesser General Public License. > > In other cases, permission to use a particular library in non-free > programs enables a greater number of people to use a large body of > free software. For example, permission to use the GNU C Library in > non-free programs enables many more people to use the whole GNU > operating system, as well as its variant, the GNU/Linux operating > system. > > Although the Lesser General Public License is Less protective of the > users' freedom, it does ensure that the user of a program that is > linked with the Library has the freedom and the wherewithal to run > that program using a modified version of the Library. > > The precise terms and conditions for copying, distribution and > modification follow. Pay close attention to the difference between a > "work based on the library" and a "work that uses the library". The > former contains code derived from the library, whereas the latter must > be combined with the library in order to run. > > GNU LESSER GENERAL PUBLIC LICENSE > TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION > > 0. This License Agreement applies to any software library or other > program which contains a notice placed by the copyright holder or > other authorized party saying it may be distributed under the terms of > this Lesser General Public License (also called "this License"). > Each licensee is addressed as "you". > > A "library" means a collection of software functions and/or data > prepared so as to be conveniently linked with application programs > (which use some of those functions and data) to form executables. > > The "Library", below, refers to any such software library or work > which has been distributed under these terms. A "work based on the > Library" means either the Library or any derivative work under > copyright law: that is to say, a work containing the Library or a > portion of it, either verbatim or with modifications and/or translated > straightforwardly into another language. (Hereinafter, translation is > included without limitation in the term "modification".) > > "Source code" for a work means the preferred form of the work for > making modifications to it. For a library, complete source code means > all the source code for all modules it contains, plus any associated > interface definition files, plus the scripts used to control compilation > and installation of the library. > > Activities other than copying, distribution and modification are not > covered by this License; they are outside its scope. The act of > running a program using the Library is not restricted, and output from > such a program is covered only if its contents constitute a work based > on the Library (independent of the use of the Library in a tool for > writing it). Whether that is true depends on what the Library does > and what the program that uses the Library does. > > 1. You may copy and distribute verbatim copies of the Library's > complete source code as you receive it, in any medium, provided that > you conspicuously and appropriately publish on each copy an > appropriate copyright notice and disclaimer of warranty; keep intact > all the notices that refer to this License and to the absence of any > warranty; and distribute a copy of this License along with the > Library. > > You may charge a fee for the physical act of transferring a copy, > and you may at your option offer warranty protection in exchange for a > fee. > > 2. You may modify your copy or copies of the Library or any portion > of it, thus forming a work based on the Library, and copy and > distribute such modifications or work under the terms of Section 1 > above, provided that you also meet all of these conditions: > > a) The modified work must itself be a software library. > > b) You must cause the files modified to carry prominent notices > stating that you changed the files and the date of any change. > > c) You must cause the whole of the work to be licensed at no > charge to all third parties under the terms of this License. > > d) If a facility in the modified Library refers to a function or a > table of data to be supplied by an application program that uses > the facility, other than as an argument passed when the facility > is invoked, then you must make a good faith effort to ensure that, > in the event an application does not supply such function or > table, the facility still operates, and performs whatever part of > its purpose remains meaningful. > > (For example, a function in a library to compute square roots has > a purpose that is entirely well-defined independent of the > application. Therefore, Subsection 2d requires that any > application-supplied function or table used by this function must > be optional: if the application does not supply it, the square > root function must still compute square roots.) > > These requirements apply to the modified work as a whole. If > identifiable sections of that work are not derived from the Library, > and can be reasonably considered independent and separate works in > themselves, then this License, and its terms, do not apply to those > sections when you distribute them as separate works. But when you > distribute the same sections as part of a whole which is a work based > on the Library, the distribution of the whole must be on the terms of > this License, whose permissions for other licensees extend to the > entire whole, and thus to each and every part regardless of who wrote > it. > > Thus, it is not the intent of this section to claim rights or contest > your rights to work written entirely by you; rather, the intent is to > exercise the right to control the distribution of derivative or > collective works based on the Library. > > In addition, mere aggregation of another work not based on the Library > with the Library (or with a work based on the Library) on a volume of > a storage or distribution medium does not bring the other work under > the scope of this License. > > 3. You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. To do > this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version 2, > instead of to this License. (If a newer version than version 2 of the > ordinary GNU General Public License has appeared, then you can specify > that version instead if you wish.) Do not make any other change in > these notices. > > Once this change is made in a given copy, it is irreversible for > that copy, so the ordinary GNU General Public License applies to all > subsequent copies and derivative works made from that copy. > > This option is useful when you wish to copy part of the code of > the Library into a program that is not a library. > > 4. You may copy and distribute the Library (or a portion or > derivative of it, under Section 2) in object code or executable form > under the terms of Sections 1 and 2 above provided that you accompany > it with the complete corresponding machine-readable source code, which > must be distributed under the terms of Sections 1 and 2 above on a > medium customarily used for software interchange. > > If distribution of object code is made by offering access to copy > from a designated place, then offering equivalent access to copy the > source code from the same place satisfies the requirement to > distribute the source code, even though third parties are not > compelled to copy the source along with the object code. > > 5. A program that contains no derivative of any portion of the > Library, but is designed to work with the Library by being compiled or > linked with it, is called a "work that uses the Library". Such a > work, in isolation, is not a derivative work of the Library, and > therefore falls outside the scope of this License. > > However, linking a "work that uses the Library" with the Library > creates an executable that is a derivative of the Library (because it > contains portions of the Library), rather than a "work that uses the > library". The executable is therefore covered by this License. > Section 6 states terms for distribution of such executables. > > When a "work that uses the Library" uses material from a header file > that is part of the Library, the object code for the work may be a > derivative work of the Library even though the source code is not. > Whether this is true is especially significant if the work can be > linked without the Library, or if the work is itself a library. The > threshold for this to be true is not precisely defined by law. > > If such an object file uses only numerical parameters, data > structure layouts and accessors, and small macros and small inline > functions (ten lines or less in length), then the use of the object > file is unrestricted, regardless of whether it is legally a derivative > work. (Executables containing this object code plus portions of the > Library will still fall under Section 6.) > > Otherwise, if the work is a derivative of the Library, you may > distribute the object code for the work under the terms of Section 6. > Any executables containing that work also fall under Section 6, > whether or not they are linked directly with the Library itself. > > 6. As an exception to the Sections above, you may also combine or > link a "work that uses the Library" with the Library to produce a > work containing portions of the Library, and distribute that work > under terms of your choice, provided that the terms permit > modification of the work for the customer's own use and reverse > engineering for debugging such modifications. > > You must give prominent notice with each copy of the work that the > Library is used in it and that the Library and its use are covered by > this License. You must supply a copy of this License. If the work > during execution displays copyright notices, you must include the > copyright notice for the Library among them, as well as a reference > directing the user to the copy of this License. Also, you must do one > of these things: > > a) Accompany the work with the complete corresponding > machine-readable source code for the Library including whatever > changes were used in the work (which must be distributed under > Sections 1 and 2 above); and, if the work is an executable linked > with the Library, with the complete machine-readable "work that > uses the Library", as object code and/or source code, so that the > user can modify the Library and then relink to produce a modified > executable containing the modified Library. (It is understood > that the user who changes the contents of definitions files in the > Library will not necessarily be able to recompile the application > to use the modified definitions.) > > b) Use a suitable shared library mechanism for linking with the > Library. A suitable mechanism is one that (1) uses at run time a > copy of the library already present on the user's computer system, > rather than copying library functions into the executable, and (2) > will operate properly with a modified version of the library, if > the user installs one, as long as the modified version is > interface-compatible with the version that the work was made with. > > c) Accompany the work with a written offer, valid for at > least three years, to give the same user the materials > specified in Subsection 6a, above, for a charge no more > than the cost of performing this distribution. > > d) If distribution of the work is made by offering access to copy > from a designated place, offer equivalent access to copy the above > specified materials from the same place. > > e) Verify that the user has already received a copy of these > materials or that you have already sent this user a copy. > > For an executable, the required form of the "work that uses the > Library" must include any data and utility programs needed for > reproducing the executable from it. However, as a special exception, > the materials to be distributed need not include anything that is > normally distributed (in either source or binary form) with the major > components (compiler, kernel, and so on) of the operating system on > which the executable runs, unless that component itself accompanies > the executable. > > It may happen that this requirement contradicts the license > restrictions of other proprietary libraries that do not normally > accompany the operating system. Such a contradiction means you cannot > use both them and the Library together in an executable that you > distribute. > > 7. You may place library facilities that are a work based on the > Library side-by-side in a single library together with other library > facilities not covered by this License, and distribute such a combined > library, provided that the separate distribution of the work based on > the Library and of the other library facilities is otherwise > permitted, and provided that you do these two things: > > a) Accompany the combined library with a copy of the same work > based on the Library, uncombined with any other library > facilities. This must be distributed under the terms of the > Sections above. > > b) Give prominent notice with the combined library of the fact > that part of it is a work based on the Library, and explaining > where to find the accompanying uncombined form of the same work. > > 8. You may not copy, modify, sublicense, link with, or distribute > the Library except as expressly provided under this License. Any > attempt otherwise to copy, modify, sublicense, link with, or > distribute the Library is void, and will automatically terminate your > rights under this License. However, parties who have received copies, > or rights, from you under this License will not have their licenses > terminated so long as such parties remain in full compliance. > > 9. You are not required to accept this License, since you have not > signed it. However, nothing else grants you permission to modify or > distribute the Library or its derivative works. These actions are > prohibited by law if you do not accept this License. Therefore, by > modifying or distributing the Library (or any work based on the > Library), you indicate your acceptance of this License to do so, and > all its terms and conditions for copying, distributing or modifying > the Library or works based on it. > > 10. Each time you redistribute the Library (or any work based on the > Library), the recipient automatically receives a license from the > original licensor to copy, distribute, link with or modify the Library > subject to these terms and conditions. You may not impose any further > restrictions on the recipients' exercise of the rights granted herein. > You are not responsible for enforcing compliance by third parties with > this License. > > 11. If, as a consequence of a court judgment or allegation of patent > infringement or for any other reason (not limited to patent issues), > conditions are imposed on you (whether by court order, agreement or > otherwise) that contradict the conditions of this License, they do not > excuse you from the conditions of this License. If you cannot > distribute so as to satisfy simultaneously your obligations under this > License and any other pertinent obligations, then as a consequence you > may not distribute the Library at all. For example, if a patent > license would not permit royalty-free redistribution of the Library by > all those who receive copies directly or indirectly through you, then > the only way you could satisfy both it and this License would be to > refrain entirely from distribution of the Library. > > If any portion of this section is held invalid or unenforceable under any > particular circumstance, the balance of the section is intended to apply, > and the section as a whole is intended to apply in other circumstances. > > It is not the purpose of this section to induce you to infringe any > patents or other property right claims or to contest validity of any > such claims; this section has the sole purpose of protecting the > integrity of the free software distribution system which is > implemented by public license practices. Many people have made > generous contributions to the wide range of software distributed > through that system in reliance on consistent application of that > system; it is up to the author/donor to decide if he or she is willing > to distribute software through any other system and a licensee cannot > impose that choice. > > This section is intended to make thoroughly clear what is believed to > be a consequence of the rest of this License. > > 12. If the distribution and/or use of the Library is restricted in > certain countries either by patents or by copyrighted interfaces, the > original copyright holder who places the Library under this License may add > an explicit geographical distribution limitation excluding those countries, > so that distribution is permitted only in or among countries not thus > excluded. In such case, this License incorporates the limitation as if > written in the body of this License. > > 13. The Free Software Foundation may publish revised and/or new > versions of the Lesser General Public License from time to time. > Such new versions will be similar in spirit to the present version, > but may differ in detail to address new problems or concerns. > > Each version is given a distinguishing version number. If the Library > specifies a version number of this License which applies to it and > "any later version", you have the option of following the terms and > conditions either of that version or of any later version published by > the Free Software Foundation. If the Library does not specify a > license version number, you may choose any version ever published by > the Free Software Foundation. > > 14. If you wish to incorporate parts of the Library into other free > programs whose distribution conditions are incompatible with these, > write to the author to ask for permission. For software which is > copyrighted by the Free Software Foundation, write to the Free > Software Foundation; we sometimes make exceptions for this. Our > decision will be guided by the two goals of preserving the free status > of all derivatives of our free software and of promoting the sharing > and reuse of software generally. > > NO WARRANTY > > 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO > WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. > EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR > OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY > KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE > IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE > LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME > THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. > > 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN > WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY > AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU > FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR > CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE > LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING > RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A > FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF > SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH > DAMAGES. > > END OF TERMS AND CONDITIONS > > How to Apply These Terms to Your New Libraries > > If you develop a new library, and you want it to be of the greatest > possible use to the public, we recommend making it free software that > everyone can redistribute and change. You can do so by permitting > redistribution under these terms (or, alternatively, under the terms of the > ordinary General Public License). > > To apply these terms, attach the following notices to the library. It is > safest to attach them to the start of each source file to most effectively > convey the exclusion of warranty; and each file should have at least the > "copyright" line and a pointer to where the full notice is found. > > > Copyright (C) > > This library is free software; you can redistribute it and/or > modify it under the terms of the GNU Lesser General Public > License as published by the Free Software Foundation; either > version 2.1 of the License, or (at your option) any later version. > > This library is distributed in the hope that it will be useful, > but WITHOUT ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > Lesser General Public License for more details. > > You should have received a copy of the GNU Lesser General Public > License along with this library; if not, write to the Free Software > Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > > Also add information on how to contact you by electronic and paper mail. > > You should also get your employer (if you work as a programmer) or your > school, if any, to sign a "copyright disclaimer" for the library, if > necessary. Here is a sample; alter the names: > > Yoyodyne, Inc., hereby disclaims all copyright interest in the > library `Frob' (a library for tweaking knobs) written by James Random Hacker. > > , 1 April 1990 > Ty Coon, President of Vice > > That's all there is to it! > ------------------------ end of proposed license ------------------ > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From gjhanna at gmail.com Sun Mar 11 14:21:17 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Mon, 12 Mar 2007 09:21:17 +1300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hi Pavel, We are using RXTX under VMWare server in production, quite satisfactorily. We're using Red Hat Enterprise Server 4, and ... Whatever the "enterprise" VMWare product is. Regards, Greg H > Subject: [Rxtx] RXTX under VMWare server > To: rxtx at qbang.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. [ ... snip ... ] -- Pavel Parkhomenko -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070311/4cebb6f9/attachment-0008.html From gergg at cox.net Sun Mar 11 23:39:19 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 12 Mar 2007 00:39:19 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: <45F4E787.6050502@cox.net> Trent Jarvi wrote: > I can start going through the method interfaces later this week and giving > feedback. I would suggest that the JSR should not be too generic in > nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel > drivers that intend to look like EIA232 ports at the kernel driver level. > > some ideas: > > EIA232PortInterface > TermiosInterface > SerialPortInterface > > Something that differentiates this from thing like USB, I2C, ... which > should not have to deal with legacy serial claiming to be the comm api. I'm going to throw out a suggestion, which I am mostly serious about. What would happen if we took the appropriate bits of the J2ME connector API, and just used that as the new COMM API so that finally JSE and JME had a common foundation for these kinds of things? Gregg Wonderly From ra85551 at gmail.com Mon Mar 12 09:08:37 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Mon, 12 Mar 2007 18:08:37 +0300 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Should any application use the modem, HyperTerminal won't be able to talk to the modem. But it actually can send and receive AT comands, while my application cannot :-( > Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Thansk for the reference. I examined that example and found that there's no significant differences between my read/write implementation and that one, except that SimpleSnuV1 listens for serialEvent's, but not for sake of data retrieval, just for printing them out - I don't know why ;-) > Note that modems could care less what OS is on top. If you are trying to > match new lines to the OS and sending it to the mode for AT commands, > thats probably a mistake. I do send strings to serial port, not to OS, and do try to get answers back. If it is the mistake, what's the right way? > Also it would not hurt to print out the > individual bytes that you are sending to make sure they did not get > mangled along the path. Yeah, I am printing these bytes before doing write, but it means that I only see what I intend to write. How can I ensure that these bytes have gone out of the box and reached my modem? BTW, I found that my send/receive method is complex enough, so I've rewritten it. Please, see the following code and point any mistakes, because I don't know where can they remain yet. private static final int LARGE_TIMEOUT = 15000; private static final int SMALL_TIMEOUT = 500; ... private String sendATCommand(String command, String waitFor, boolean isRegex, boolean isAddCRLF) throws BeaconConnectException { byte[] buffer = new byte[512]; int offset; String result = ""; try { if (waitFor != null) { serialPort.enableReceiveTimeout(LARGE_TIMEOUT); } else { serialPort.enableReceiveTimeout(SMALL_TIMEOUT); } if (command != null) { OutputStream serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } offset = 0; InputStream serialInput = serialPort.getInputStream(); while (serialInput.available() != -1) { int bytesRead = serialInput.read(buffer, offset, buffer.length - offset); if (bytesRead == 0) { break; } offset += bytesRead; result = new String(buffer, 0, offset).trim(); if (waitFor != null) { System.out.println(result); if (isRegex && result.matches(waitFor) || result.contains(waitFor)) { break; } } } } catch (UnsupportedCommOperationException e) { throw new MyException("unsupported operation"); } catch (IOException e) { throw new MytException("serial I/O error"); } return result; } -- Pavel Parkhomenko From clayno at hotpop.com Thu Mar 15 02:47:34 2007 From: clayno at hotpop.com (Christopher Layno) Date: Thu, 15 Mar 2007 16:47:34 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi, we're using the latest release of rxtx (2.1-7r2) for our system that has two applications using the library. one application sends requests to the modem while the other simply checks the modem status. we deployed our system on a pentium machine with red hat linux 9.0 installed. now the problem arises when these two applications try to access the same modem at the same time. one of them will eventually have to throw the PortInUseException as shown below: 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException gnu.io.PortInUseException: root PID = 743 Program = java root PID = 743 Program = java root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) this was expected. what we didn't expect though was that if we repeat the scenario 5 times, always 5 times, the application would also throw a VM error: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4473CD21 Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so Current Java thread: at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) - locked <0x44cfd4c8> (a gnu.io.CommPortIdentifier) at ************ at ************ - locked <0x4476a468> (a **********) at ************ at ************ at ************ at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java :261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages( TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run( TCPTransport.java:701) at java.lang.Thread.run(Thread.java:534) note: i replaced some sensitive data with asterisks our team has looked everywhere on the internet, including your mail archives, for a solution to this problem but to no avail. i really hope you could help us out on this one. thanks in advance! best regards, chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070315/1936460a/attachment-0008.html From tjarvi at qbang.org Fri Mar 16 04:30:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 04:30:25 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: On Thu, 15 Mar 2007, Christopher Layno wrote: > hi, > > we're using the latest release of rxtx (2.1-7r2) for our system that has two > applications using the library. one application sends requests to the modem > while the other simply checks the modem status. we deployed our system on a > pentium machine with red hat linux 9.0 installed. > > now the problem arises when these two applications try to access the same > modem at the same time. one of them will eventually have to throw the > PortInUseException as shown below: > > 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException > gnu.io.PortInUseException: root PID = 743 Program = java root PID = > 743 Program = java root PID = 743 Program = ??? root PID = 743 Program > = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root > PID = 743 Program = ??? root PID = 743 Program = ??? > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > > this was expected. what we didn't expect though was that if we repeat the > scenario 5 times, always 5 times, the application would also throw a VM > error: > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x4473CD21 > Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 > Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so > > Current Java thread: > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) Hi Chris The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. The code is originally by Werner Almesberger. He gave us permission to use it in rxtx. You might look at what has changed since 1998 in his fuser application. Or you can just do like other OSs and do the following in fuserImp.c JNIEXPORT jstring JNICALL Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv *env, jobject obj, jstring arg) { return (*env)->NewStringUTF(env, "Unknown Application"); } It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. -- Trent Jarvi tjarvi at qang.org From Adrien.TOS at ingenico.com Fri Mar 16 05:11:12 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Fri, 16 Mar 2007 12:11:12 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903CBC312@frsnprexc1.usr.ingenico.loc> Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070316/972ab214/attachment-0008.html From joachim at buechse.de Fri Mar 16 05:13:24 2007 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 16 Mar 2007 12:13:24 +0100 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. From tjarvi at qbang.org Fri Mar 16 16:36:29 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 16:36:29 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Fri Mar 16 16:02:23 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 16 Mar 2007 18:02:23 -0400 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Not all platforms are Unix based. Also mixing native library usage and command-line calls is not an elegant solution, IMHO. One or the other, but not both. Andre On 16-Mar-07, at 07:13 , Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is > trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We >> only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From clayno at hotpop.com Sun Mar 18 22:17:28 2007 From: clayno at hotpop.com (Christopher Layno) Date: Mon, 19 Mar 2007 12:17:28 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi everyone, thank you so much for your replies. they were really helpful. anyway, before i sent the email, my team was already implementing a temporary solution by using joachim's suggestion. we invoked a lsof command from our java code although i share the same concern with trent and andre-john about portability issues. that's why i said it's just temporary. my superiors have yet to approve our bug fix. so my question now is this: is recompiling the rxtx source code the only way to solve this problem? because if it's the only solution, then i think my superiors would rather have a new release from the rxtx community itself that fixes this bug(?) rather than have my team recompile the source code. best regards, chris Trent Jarvi wrote: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. ... It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070318/237463b2/attachment-0008.html From tjarvi at qbang.org Mon Mar 19 16:20:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Mar 2007 16:20:52 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: Hi Chris I can compile a new version after the 21st if you do not feel comfortable doing so. Please send me an email reminder off-line then. On Mon, 19 Mar 2007, Christopher Layno wrote: > hi everyone, > > thank you so much for your replies. they were really helpful. > > anyway, before i sent the email, my team was already implementing a > temporary solution by using joachim's suggestion. > we invoked a lsof command from our java code although i share the same > concern with trent and andre-john about > portability issues. that's why i said it's just temporary. my superiors have > yet to approve our bug fix. > > so my question now is this: is recompiling the rxtx source code the only way > to solve this problem? because if it's the only > solution, then i think my superiors would rather have a new release from the > rxtx community itself that fixes this bug(?) > rather than have my team recompile the source code. > > best regards, > > chris > > Trent Jarvi wrote: > > Hi Joachim > > It would be nice to have that functionality but calling the program > introduces too many issues imho. Explaining to someone why rxtx invoked a > rogue lsof does not sound very interesting. > > On Fri, 16 Mar 2007, Joachim Buechse wrote: > > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: > > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. > > _______________________________________________ > Rxtx mailing list > Rxtx 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 Eric.Arseneau at sun.com Tue Mar 20 11:47:33 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Tue, 20 Mar 2007 10:47:33 -0700 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 Message-ID: <46001E35.9040608@sun.com> Anyone have any experience with RXTX working with JDK 6 on other platforms ? From mm at UDel.Edu Tue Mar 20 12:18:29 2007 From: mm at UDel.Edu (Mike Markowski) Date: Tue, 20 Mar 2007 14:18:29 -0400 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 In-Reply-To: <46001E35.9040608@sun.com> References: <46001E35.9040608@sun.com> Message-ID: <46002575.4000306@udel.edu> Eric Arseneau wrote: > Anyone have any experience with RXTX working with JDK 6 on other platforms ? I'm using 32 bit intel, gentoo linux, jdk6 with no problems. My applications only use a serial port, though, nothing on the parallel port. Mike From falko.guderian at gmx.de Wed Mar 21 08:17:35 2007 From: falko.guderian at gmx.de (Falko Guderian) Date: Wed, 21 Mar 2007 15:17:35 +0100 Subject: [Rxtx] RXTX binaries for SH4 Message-ID: <46013E7F.40102@gmx.de> Dear developers, I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no possiblities to compile the source code. Better, I'm not able to do this at the moment. Can you provide me with rxtxSerial.dll (SH4) in the rxtx-2.1-8-testing version? (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) The reason for the testing version is I need custom baud rates. Thanks for help. Kind regards, Falko Guderian From tjarvi at qbang.org Wed Mar 21 21:38:37 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Mar 2007 21:38:37 -0600 (MDT) Subject: [Rxtx] RXTX binaries for SH4 In-Reply-To: <46013E7F.40102@gmx.de> References: <46013E7F.40102@gmx.de> Message-ID: On Wed, 21 Mar 2007, Falko Guderian wrote: > Dear developers, > > I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no > possiblities to compile the source code. Better, I'm not able to do this > at the moment. Can you provide me with rxtxSerial.dll (SH4) in the > rxtx-2.1-8-testing version? > (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) > > The reason for the testing version is I need custom baud rates. > > Thanks for help. > Hi Falko WinCE binary format is not supported by gcc. That makes compiling limited to those familiar with the WinCE tools. I hope someone is able to provide them for you but it is not likely. WinCE has been compiled by others in the past but rxtx.org builds have never included WinCE. There is some information with the source concerning WinCE builds if you decide to do it. We can share your results too if you like. The source in the WinCE has never been updated for the custom baud rate. That would need changes from the main source I presume. If you look at the source, you will note that Michal Hobot created a mini fork in the source to handle wince but it has not been updated for 3 years. -- Trent Jarvi tjarvi at qbang.org From Adrien.TOS at ingenico.com Thu Mar 22 07:08:55 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Thu, 22 Mar 2007 14:08:55 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Hi everybody, Do you have any comments on this issue? Thanks! AT ________________________________ De : Adrien TOS Envoy? : vendredi 16 mars 2007 12:11 ? : 'rxtx at qbang.org' Cc : Adrien TOS Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070322/2306c538/attachment-0008.html From jeremy.reeve at zen.co.uk Mon Mar 19 07:36:04 2007 From: jeremy.reeve at zen.co.uk (Jeremy S. Reeve) Date: Mon, 19 Mar 2007 13:36:04 +0000 Subject: [Rxtx] rxtx failing to compile on Fedora Core 6 Message-ID: <1174311364.21865.6.camel@d9thc> When trying to compile latest source : rxtx-2.1-7r2 I get the following when running configure: ---------------- checking os.version 2.6.18-1.2200.fc5smp WARNING: configure is having a hard time determining which directory contains the file jni_md.h. Edit Makefile and fix the variable JAVANATINC to point to the correct directory. The following options are available: /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/ /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/linux/ If there are more than one option available the first was selected. WARNING: Kernel include files do not match the current kernel configure: creating ./config.status ------------------------ which seems OK checking the resultant Makefile but when attempting to build with gmake install I get the following output : ---------------------- 34 problems (34 warnings)/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/javah -classpath .:/home/jsr/rxtxsrc/rxtx-2.1-7r2:/home/jsr/rxtxsrc/rxtx-2.1-7r2/src:/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/ext/RXTXcomm.jar -d i686-pc-linux-gnu -jni `(for i in CommDriver CommPortEnumerator CommPortIdentifier CommPort CommPortOwnershipListener Configure I2C I2CPortEvent I2CPortEventListener I2CPort LPRPort NoSuchPortException ParallelPortEvent ParallelPortEventListener ParallelPort PortInUseException Raw RawPortEvent RawPortEventListener RawPort RS485 RS485PortEvent RS485PortEventListener RS485Port RXTXCommDriver RXTXPort RXTXVersion SerialPortEvent SerialPortEventListener SerialPort UnsupportedCommOperationException UnSupportedLoggerException Zystem;do \ if grep > /dev/null native.* \( /home/jsr/rxtxsrc/rxtx-2.1-7r2/./src/$i.java; then \ echo gnu.io.$i; \ fi; \ done)` i686-pc-linux-gnu/gnu_io_CommPortIdentifier.h: No such file or directory make: *** [/home/jsr/rxtxsrc/rxtx-2.1-7r2/gnu/io/CommDriver.class] Error 1 ------------------------ Any ideas or pointers? Regards, Jeremy From tjarvi at qbang.org Sat Mar 24 08:12:54 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 Mar 2007 08:12:54 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > From Adrien.TOS at ingenico.com Sat Mar 24 11:53:22 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Sat, 24 Mar 2007 18:53:22 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> I do not have the threshold setting enabled, I have explicitely disabled it with: port_.disableReceiveThreshold(); I have also run the same tests with the threshold setting enabled, but they also fail in the same way as described below. So it seems there is a problem with timeout handling on Win32? ________________________________ From: rxtx-bounces at qbang.org on behalf of Trent Jarvi Sent: Sat 3/24/2007 3:12 PM To: RXTX Developers and Users Subject: Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 8312 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20070324/f9e39c9b/attachment-0008.bin From greg.johnson at manchester.ac.uk Sun Mar 25 13:41:36 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Sun, 25 Mar 2007 21:41:36 +0200 Subject: [Rxtx] Mac intel weirdness Message-ID: Hi folks, I'm trying to get rxtx to work on my macbook pro with a USB-serial dongle on it. I am using the 2.1-8 code from the CVS (though it seems to report itself as 2.1-7: makes it difficult to prove to oneself that the changes have 'taken'! - line 4210 in SerialImp.c, line 40 in RXTXVersion.java) I am trying the 2.1-8 because of horrible lock problems in 2.1-7. However, the serialport closure code seems to be broken - it won't close because it believes the (previously opened!) port doesn't exist. Here is what I'm trying: 0. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "false" 1. Open a port Serialport serialport = (SerialPort) commportidentifier.open ("test",100); 2. Talk to a device ... 3. Close port serialport.close(); 4. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "true" - why is this? 5. Try to reopen port Serialport serialport2 = (SerialPort) commportidentifier.open("test", 100); throws PortInUseException. I've dug around a bit in the source, and it seems the SerialPort.close () should call the CommPortIdentifier.internalClosePort() (line 67 of CommPort.java). However, I crash out with the NoSuchPortException when getPortIdentifier is called. Which seems quite weird to me, seeing as it is called on this - which was create just beforehand. Does anyone know how to fix this? Cheers, greg From knute at frazmtn.com Sat Mar 24 10:32:38 2007 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 24 Mar 2007 09:32:38 -0700 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc>, Message-ID: <4604F036.17833.135298@knute.frazmtn.com> > >The behavior of timeout depends upon the setting of the threshold. Do you >have the threshold setting? > This is the same bug I reported last fall. There was a fellow that sent me an email asking if it had been fixed. I told him I didn't think so. He got somebody to write a fix for him but I have not been able to contact him again for the actual changes. The inaccurate timeout and the failure of blocking when no timeouts are set is a serious bug in my humble opinion and renders the software unusable for my applications. I'd really like to have an alternative to the Sun comm api but there just isn't one that I know of. -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Mar 26 16:17:00 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 26 Mar 2007 16:17:00 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> Message-ID: >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. From ra85551 at gmail.com Tue Mar 27 10:18:36 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Tue, 27 Mar 2007 20:18:36 +0400 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Ultimately I found a solution. At first, that wasn't actually the VMWare + WinXP + RXTX issue, that was WinXP + RXTX issue. But on pure XP it sometimes workes, sometimes not, while under VMWare I had never seen my snippet working at all. SimpleSnuV1.java would not help me, because there is only one line I missed, and SimpleSnuV1.java also doesn't contain it! It is as follows: serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_OUT | SerialPort.FLOWCONTROL_RTSCTS_IN); Thank you for your attention. -- Pavel Parkhomenko From griff at op.pl Wed Mar 28 01:28:19 2007 From: griff at op.pl (griff@op.pl) Date: Wed, 28 Mar 2007 09:28:19 +0200 Subject: [Rxtx] No blocking read on Windows. Message-ID: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/5d07d571/attachment-0008.html -------------- next part -------------- Hi, I have problem that InputStram.read() (SerialPort)?returns -1 instead blocking and waiting for data. I found that this problem was ?known in 2005 : ? >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > >> Hi Trent >> >> Thanks for the fast response. >> Here's a Q&D test program for the blocking read on windows that just >> attempts to read one byte, and prints the resulting byte. On my system it >> returns -1, where I expect that it keeps waiting for data. >> >This isn't happening on Linux so the bug is in src/termios.c.? I'll have >something this weekend to fix that. I'm using RXTX 2.1.7r2 and the problem still is here. Im using Windows XP and java 1.5 disableReciveTimeout() and disableReciveTreshhold() dont help. ? best regards ? Piotr Zielniok From Adrien.TOS at ingenico.com Wed Mar 28 01:40:46 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Wed, 28 Mar 2007 09:40:46 +0200 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903E88880@frsnprexc1.usr.ingenico.loc> Looking at the code, it seems there is no support for infinite timeout? And maybe the count++ < 20 condition is breaking out of the loop too early? The only condition to break out of the loop should either be the timeout has expired or the number of requested bytes has been received. -----Message d'origine----- De : rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] De la part de Trent Jarvi Envoy? : mardi 27 mars 2007 00:17 ? : RXTX Developers and Users Objet : Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From j.kenneth.gentle at acm.org Wed Mar 28 06:44:15 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 28 Mar 2007 08:44:15 -0400 Subject: [Rxtx] No blocking read on Windows. In-Reply-To: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> References: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> Message-ID: <200703281844.l2SIiITW028614@qbang.org> Just another "ME TOO!" - I'm seeing this problem on Windows XP, jre for windows XP/Embedded. I cranked receiveTimeout up to Integer.MAX_INT, but it doesn't seem to wait that long At 03:28 2007-03-28, you wrote: >Hi, >I have problem that InputStram.read() (SerialPort) returns -1 >instead blocking and waiting for data. I found that this problem >was known in 2005 : > > >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > > > >> Hi Trent > >> > >> Thanks for the fast response. > >> Here's a Q&D test program for the blocking read on windows that just > >> attempts to read one byte, and prints the resulting byte. On my system it > >> returns -1, where I expect that it keeps waiting for data. > >> > > >This isn't happening on Linux so the bug is in src/termios.c. I'll have > >something this weekend to fix that. > >I'm using RXTX 2.1.7r2 and the problem still is here. >Im using Windows XP and java 1.5 >disableReciveTimeout() and disableReciveTreshhold() dont help. > >best regards > >Piotr Zielniok > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From greg.johnson at manchester.ac.uk Wed Mar 28 14:43:29 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Wed, 28 Mar 2007 22:43:29 +0200 Subject: [Rxtx] Cannot close and reopen serial port Message-ID: <377F9765-7A9D-4CE9-9176-FFB63A2594F0@manchester.ac.uk> Dear all, It appears I cannot close a port properly: SerialPort serialport = portid.open("myprog",100); // do some stuff, all works fine serialport.close(); // all seems fine but... SerialPort sp2 = portid.open("myprog",100); throws PortInUseException. And when I dig into the rxtx code, I find in CommPort.java, in close(): CommPortIdentifier cp = CommPortIdentifier.getPortIdentifier(this); (line 64 or there abouts) but this throws a NoSuchPortException which is caught but ignored (line 74ish). Can anyone suggest how this could happen: a port that was valid, opened, and used, throws a NSPE when it comes to closing it? I'm pulling my (remaining) hair out over this one! Cheers, greg PS And thanks for RXTX - it's great to have! PPS (21.-7. winxp/osx both, java 1.5) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/c28852fc/attachment-0008.html From rxtx at vrijheidslaan.net Fri Mar 30 16:52:50 2007 From: rxtx at vrijheidslaan.net (Rob) Date: Fri, 30 Mar 2007 22:52:50 -0000 Subject: [Rxtx] Cvs Question Message-ID: <61896.80.126.150.87.1175295162.squirrel@webmail.provalue.nl> Hi There, Im trying to get the latest version to work on mac osx. Problem is that i can't checkout version 2.1.8. Probably my fault but can some one please give me the alternative commands for: [user at myhost]$ export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot [user at myhost]$ cvs login Thanx, Rob From ra85551 at gmail.com Thu Mar 1 03:47:06 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Thu, 1 Mar 2007 13:47:06 +0300 Subject: [Rxtx] enableReceiveTimeout() issue Message-ID: Hello, world! I found a limitation of 16300 ms for CommPort's enableReceiveTimeout() method, while in original javax.comm docs there are no any references to that. Is that a bug or feature? I actually need longer timeouts sometimees. -- Pavel Parkhomenko From lyon at docjava.com Thu Mar 1 07:54:17 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 01 Mar 2007 09:54:17 -0500 Subject: [Rxtx] parametric singleton design pattern In-Reply-To: References: <22d55aea0702081207q5e7f6785l352d498d6f5f9fb1@mail.gmail.com> <22d55aea0702100034o3bcf42f3j1d1a6257029a67b0@mail.gmail.com> Message-ID: Hi All, I have been thinking about the use of a design pattern to cache resources that are consumed by processes. Toward that end, I have arrived at a parametric singleton design pattern, which I mentioned on this list some time ago. The idea has been published at: http://www.jot.fm/issues/issue_2007_03/column2 I can't help but think that there should be an API available for dealing with the tracking of serial port usage. Perhaps it is a kind of resource manager called the: SerialPortManager basic prototypes already exist in this vain. See, for example: http://www.ce.rit.edu/research/projects/2005_fall/rt_poolsystem/doc/PoolMon/SerialPortManager.html http://www.eventhelix.com/RealtimeMantra/PatternCatalog/serial_port_design_pattern.htm And others shown by a google search on "SerialPortManager" Cheers! - Doug From Eric.Arseneau at sun.com Thu Mar 1 10:15:03 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:15:03 -0800 Subject: [Rxtx] Any known Java 6 issues with RXTX 2.1-7r2 ? Message-ID: <45E70A17.1060206@sun.com> I just did a test on a recent build of Solaris 11 x86 and it seems that I can connect to my serial device fine when Java 5 is the default, but when Java 6 is the default, no go. Any information ? From Eric.Arseneau at sun.com Thu Mar 1 10:19:58 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:19:58 -0800 Subject: [Rxtx] Mac OS X and missing data Message-ID: <45E70B3E.7040908@sun.com> We have a device which is USB based but presents itself as a serial port to a machine. On my MacBook Pro I can get excellent throughput if I get my device to send data as quickly as possible. On the desktop side, if I do an type of disk IO to log the data I get, I end up with some missing data at some point. I hooked up a USB analyzer and did confirm that all the data is sent as expected to the desktop from the device. I found a work around for this, buffer the data in memory and only write the data out when I've received it all. However, when the same code and same device is attempted on a co-workers MacBook Pro (same hardware specs), I get errors and must slow down dramatically the device side's sending of data. Any ideas/recommendations on what I can do to get rid of this error ? From what I can tell, it seems that RXTX is not able to wake up to the interrupts coming in indicating data is ready, quickly enough, is there anything I can do ? From chinkaiw at hotmail.com Fri Mar 2 00:57:43 2007 From: chinkaiw at hotmail.com (Wang Chinkai) Date: Fri, 02 Mar 2007 07:57:43 +0000 Subject: [Rxtx] dynamic detect rs232 port Message-ID: Hi all I have a question about detecting rs232 port dynamicly. I have to aceess some port and detect rs232 port at the same time. Some usb device simulates rs232 port , and I can not know what the port name it gets until it connects,so I have to detect it dynamic,but I have to access another rs232 device at the same time. I found a problem. If I use CommPortIdentifier.getPortIdentifiers() to get new port list , and the other rs232 access function will not close port correctly. So , How can I solve it . Thanks. _________________________________________________________________ ?? 2GB ???? Windows Live Mail ????????????? http://ideas.live.com/programpage.aspx?versionid=5d21c51a-b161-4314-9b0e-4911fb2b2e6d From eu259473 at tele2.it Fri Mar 2 06:16:40 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 02 Mar 2007 14:16:40 +0100 Subject: [Rxtx] rxtx on HP tru 64 unix Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070302/706c7a70/attachment-0009.html From tjarvi at qbang.org Fri Mar 2 08:39:33 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 08:39:33 -0700 (MST) Subject: [Rxtx] rxtx on HP tru 64 unix In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, "Giuseppe Marchese" wrote: > Hi > > I try to install rxtx on hp tru 64 but make fails, > There are somebody that do the same and work. > > > Sorry for may english! > > Hi Giuseppe Could you provide a log of the failure? script ./configure make # use gnu make exit The information will be in the typescript created. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 2 19:56:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 19:56:52 -0700 (MST) Subject: [Rxtx] dynamic detect rs232 port In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, Wang Chinkai wrote: > Hi all > > I have a question about detecting rs232 port dynamicly. > > I have to aceess some port and detect rs232 port at the same time. > Some usb device simulates rs232 port , and I can not know > what the port name it gets until it connects,so I have to detect it > dynamic,but I have to access > another rs232 device at the same time. > > I found a problem. Hi Wang This is a known problem. The code is braindead there. In fact there needs to be events even in a rudamentary way when you add a usb dongle. I'm burried in tasks not far from rxtx but not in rxtx. I can't get to the problem but we would accept patches if you dig into it. [I'm getting to the license question earlier too; I don't have another 10%] -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Fri Mar 2 23:19:01 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 01:19:01 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Hi, Under ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable USB -> serial converter(using virtual com port drivers), with using example code pretty much straight out of http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port opens fine, enumerations all work, etc. My application calls for a large amount of data to be transferred in a short amount of time at 2,000,000 baud. My hardware sends approximately 15,232 bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL converter work fine, and the application works using C++. In C++, I do a hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); to open the port, and a boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); to read the port. The variable buffer fills with the 15238 bytes, and returns. If I do a resultz = is.read(cbuf,0,15238); in java with RXTX where is = new BufferedReader(new InputStreamReader(port.getInputStream())); and where resultz is an int, and cbuf is a char [] cbuf, resultz gets EXACTLY 3968 bytes the first time called. If I call it multiple times, I get roughly 11k total(less than what is sent), never more than the 3968 bytes per is.read() call. My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 bytes. I've played with inputbuffersize, receive threshold, receivetimeout, and so on. The FTDI virtual com port drivers that I'm using are rock solid, and have had zero problems with them using a variety of applications, some of my own, some professionally written, etc. No flow control is used anyplace, no RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. No exceptions are being thrown. What am I doing wrong, and what I can adjust to receive the full 15k bytes in one single read? Thanks! Keith From Eric.Arseneau at sun.com Fri Mar 2 23:32:07 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Fri, 02 Mar 2007 22:32:07 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <45E91667.20501@sun.com> This is the same type of thing that is happening to me on Mac OS X and does not seem to behave the same on different machines. I posted a day or two ago on this with subject "Mac OS X and missing data". Would love to hear if there is a solution to this :) From tjarvi at qbang.org Sat Mar 3 10:54:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 10:54:17 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > Hi, > > Under > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable > USB -> serial converter(using virtual com port drivers), with using example > code pretty much straight out of > http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port > opens fine, enumerations all work, etc. > > My application calls for a large amount of data to be transferred in a short > amount of time at 2,000,000 baud. My hardware sends approximately 15,232 > bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL > converter work fine, and the application works using C++. > > In C++, I do a > > hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, > OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); > > to open the port, and a > > boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); > > to read the port. > > The variable buffer fills with the 15238 bytes, and returns. > > If I do a > > resultz = is.read(cbuf,0,15238); in java with RXTX > > where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > > and where resultz is an int, and cbuf is a char [] cbuf, resultz gets > EXACTLY 3968 bytes the first time called. If I call it multiple times, I get > roughly 11k total(less than what is sent), never more than the 3968 bytes > per is.read() call. > > My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 > bytes. > > I've played with inputbuffersize, receive threshold, receivetimeout, and so > on. The FTDI virtual com port drivers that I'm using are rock solid, and > have had zero problems with them using a variety of applications, some of my > own, some professionally written, etc. No flow control is used anyplace, no > RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. > > No exceptions are being thrown. > > What am I doing wrong, and what I can adjust to receive the full 15k bytes > in one single read? > > Thanks! > Hi Keith I would expect a 20 meg application is going to have different behavior with the OS than a smaller application with respect to the kernel memory managment, schedualing, ... Something subtle could be causing problems. With respect to the recieve timeout and threshold, if you set the timeout to zero and the threshold to the size of data you expect, read should not return until it get that data. You may try with a stand alone application that tests just that with the C/C++ API. If the read is returning with less data when tested for short reads, you have found a bug in the device driver more than likely. The USB dongle vendor would probably be interested in knowing about this. As mentioned, these devices are getting very good; almost bug free. I suspect you found a bug though if you did use the threshold and timeout properly. The missing data is typical when not using flow control. When the OS buffering fills, the hardware will start dropping bytes. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:38:52 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:38:52 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> update: I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now instead of 3968. This makes sense. 128 bytes of overhead + 3968 bytes of data = 4096 transfer size 32 bytes of overhead + 992 bytes of data = 1024 transfer size. 1/4 the data = 1/4 the overhead. I rearranged my reading like so: resultz = is.read(cbuf,0,3968); resultz = is.read(cbuf,3968,3968); resultz = is.read(cbuf,7936,3968); while (!(is.ready())); // wait for ready resultz = is.read(cbuf,11904,3334); and this grabs 15,238 bytes total. BUT, I still have the quandry of the screwed up multi-bytes. I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. Approx 8% of the data. The bad bytes always seem to take the flavor of 0x2018, 0x2019, x2022, x2030, x201d. Are these maybe errors and I don't know what they enumerate to? I still can't believe some other layer isn't handling putting those bytes together all in one stream for me. Thanks Keith ----- Original Message ----- From: "Keith" To: "Bob Jacobsen" ; "RXTX Developers and Users" Sent: Saturday, March 03, 2007 11:26 AM Subject: Re: [Rxtx] is.read() only returning 3968 bytes > Bob, > > > Interesting numerical coincidence is that (max USB transfer) - (what > > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > > needed to transfer that much data. > > I was thinking along the same lines. I don't know USB well, but I do know > that those numbers were close enough to warrant investigating the > relationship between them. > > > I think what you're seeing is the internal buffering of the USB data > > stream. You'll need some form of higher-level buffering to smooth > > that out. > > Shouldn't the InputStreamReader() and BufferedReader() provide this type of > buffering? Isn't that the idea behind those? > > > All hypotheses need to be tested. In this case, a test would be to > > check for missing data. If this idea is right, you'll get _all_ the > > data, but you won't be missing characters. > > I did start looking at the data. -- I'm getting weird results. > > I tried this: > > loopzz = 0; > > for (looptwo = 0; looptwo < 100000; looptwo++) { > while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > > }} > > So I'm reading one character at a time. The good news is that loopzz is > exactly 15238 at the end of the routine, which is perfectly correct. I > picked looptwo value out of thin air. > > The weird results come in terms of the values, the data isn't correct at > least in one case. Look here: > > 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > > This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). > But the 0x89 was replaced by 0x2030. Why the heck would the returned value > be 0x2030?? Why is the returned byte completely out of range? Why the > multibyte return? > > From InputStream in the API: > > read > public abstract int read() > throws IOExceptionReads the next byte of data from the > input stream. The value byte is returned as an int in the range 0 to 255. If > no byte is available because the end of the stream has been reached, the > value -1 is returned. This method blocks until input data is available, the > end of the stream is detected, or an exception is thrown. > Value should be 0-255. > > > In my application time is really critical, reading 1 byte at a time is > probably not going to work. > > Thanks Eric & Bob for looking at this. > > Keith > From tjarvi at qbang.org Sat Mar 3 12:52:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 12:52:27 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > update: > > I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now > instead of 3968. > > This makes sense. > > 128 bytes of overhead + 3968 bytes of data = 4096 transfer size > 32 bytes of overhead + 992 bytes of data = 1024 transfer size. > > 1/4 the data = 1/4 the overhead. > > I rearranged my reading like so: > > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. > Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? > > I still can't believe some other layer isn't handling putting those bytes > together all in one stream for me. > The layer for this in Serial land is flow control. Software and hardware flow control prevent the overruns you observe. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:54:41 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:54:41 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <001a01c75dcd$c8802a70$6600a8c0@jbh757ktruws7g> Trent, Thanks for taking the time to reply. > I would expect a 20 meg application is going to have different behavior > with the OS than a smaller application with respect to the kernel memory > managment, schedualing, ... Something subtle could be causing problems. Well, at least I know the VCP drivers, the OS, etc can handle 2mbps reliably. Without hiccuping or dropping bytes. The C++ code works reliably without flow control. > The missing data is typical when not using flow control. When the OS > buffering fills, the hardware will start dropping bytes. I'm actually not getting MISSING data, I'm getting CORRUPTED data. If you look at my most recent post, I'm getting these bad bytes in place of the correct values: 0x2018, 0x2019, x2022, x2030, x201d. Why would is.read() return values not in the range of 0-255 ? Thanks. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 08:59:14 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 07:59:14 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: At 1:19 AM -0500 3/3/07, Keith wrote: >If I do a > >resultz = is.read(cbuf,0,15238); in java with RXTX > >where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > >and where resultz is an int, and cbuf is a char [] cbuf, resultz gets >EXACTLY 3968 bytes the first time called. If I call it multiple times, I get >roughly 11k total(less than what is sent), never more than the 3968 bytes >per is.read() call. > >My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 >bytes. Interesting numerical coincidence is that (max USB transfer) - (what you get) = 4096-3968 = 128 bytes is (almost) the size of the headers needed to transfer that much data. I think what you're seeing is the internal buffering of the USB data stream. You'll need some form of higher-level buffering to smooth that out. All hypotheses need to be tested. In this case, a test would be to check for missing data. If this idea is right, you'll get _all_ the data, but you won't be missing characters. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 09:26:14 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 11:26:14 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Bob, > Interesting numerical coincidence is that (max USB transfer) - (what > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > needed to transfer that much data. I was thinking along the same lines. I don't know USB well, but I do know that those numbers were close enough to warrant investigating the relationship between them. > I think what you're seeing is the internal buffering of the USB data > stream. You'll need some form of higher-level buffering to smooth > that out. Shouldn't the InputStreamReader() and BufferedReader() provide this type of buffering? Isn't that the idea behind those? > All hypotheses need to be tested. In this case, a test would be to > check for missing data. If this idea is right, you'll get _all_ the > data, but you won't be missing characters. I did start looking at the data. -- I'm getting weird results. I tried this: loopzz = 0; for (looptwo = 0; looptwo < 100000; looptwo++) { while (is.ready()) { cbuf[loopzz] = (char) is.read(); loopzz++; }} So I'm reading one character at a time. The good news is that loopzz is exactly 15238 at the end of the routine, which is perfectly correct. I picked looptwo value out of thin air. The weird results come in terms of the values, the data isn't correct at least in one case. Look here: 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). But the 0x89 was replaced by 0x2030. Why the heck would the returned value be 0x2030?? Why is the returned byte completely out of range? Why the multibyte return? >From InputStream in the API: read public abstract int read() throws IOExceptionReads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown. Value should be 0-255. In my application time is really critical, reading 1 byte at a time is probably not going to work. Thanks Eric & Bob for looking at this. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 14:44:50 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 13:44:50 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: Java's "char" type is Unicode. I think what you're seeing is a bug in the byte -> Unicode translation. 0x2018, 0x2019 are the curly open and close quotes. There used to be (and might still be) bugs in the conversion of these in a couple of libc versions. Some of the ASCII -> ISO and ISO -> ASCII routines were a little over-ambitious with respect to handling the open and close quotes, and tried to convert them to the "curly" form inappropriately. Try _not_ casting it to char. Bob At 11:26 AM -0500 3/3/07, Keith wrote: >Bob, > >> Interesting numerical coincidence is that (max USB transfer) - (what >> you get) = 4096-3968 = 128 bytes is (almost) the size of the headers >> needed to transfer that much data. > >I was thinking along the same lines. I don't know USB well, but I do know >that those numbers were close enough to warrant investigating the >relationship between them. > >> I think what you're seeing is the internal buffering of the USB data >> stream. You'll need some form of higher-level buffering to smooth >> that out. > >Shouldn't the InputStreamReader() and BufferedReader() provide this type of >buffering? Isn't that the idea behind those? > >> All hypotheses need to be tested. In this case, a test would be to >> check for missing data. If this idea is right, you'll get _all_ the >> data, but you won't be missing characters. > >I did start looking at the data. -- I'm getting weird results. > >I tried this: > >loopzz = 0; > >for (looptwo = 0; looptwo < 100000; looptwo++) { >while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > >}} > >So I'm reading one character at a time. The good news is that loopzz is >exactly 15238 at the end of the routine, which is perfectly correct. I >picked looptwo value out of thin air. > >The weird results come in terms of the values, the data isn't correct at >least in one case. Look here: > >0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > >This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). >But the 0x89 was replaced by 0x2030. Why the heck would the returned value >be 0x2030?? Why is the returned byte completely out of range? Why the >multibyte return? > >>From InputStream in the API: > >read >public abstract int read() > throws IOExceptionReads the next byte of data from the >input stream. The value byte is returned as an int in the range 0 to 255. If >no byte is available because the end of the stream has been reached, the >value -1 is returned. This method blocks until input data is available, the >end of the stream is detected, or an exception is thrown. >Value should be 0-255. > > >In my application time is really critical, reading 1 byte at a time is >probably not going to work. > >Thanks Eric & Bob for looking at this. > >Keith > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 15:10:11 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 17:10:11 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Bob said ..... > Java's "char" type is Unicode. I think what you're seeing is a bug > in the byte -> Unicode translation. Bob -- I think you hit the nail on the head. I was just coming to the same realization here. I knew that something funny was going on because the same bytes always got "corrupted." I'm pretty sure its in the InputStreamReader() functionality where the conversion junk is happening. Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. I don't know if simply changing the cast is going to work. Since the conversion is happening upstream (pun intended), I don't think my cast is doing this. Also I think the compiler forced me to use the cast. I'm still playing around, and I'll report back once I nail it down. Thanks!! Keith From tjarvi at qbang.org Sat Mar 3 15:59:46 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 15:59:46 -0700 (MST) Subject: [Rxtx] Win64 rxtx Testers? Message-ID: I have compiled win64 binaries of rxtx. Are there any users interested in testing them? If so, I'll look into putting them on the web site. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Mar 3 15:35:06 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 14:35:06 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: Because of this and similar problems, JMRI does all it's serial IO using +only+ byte values. It's a but of a pain, as Java wants to go to char and int types a little too aggressively, but it does solve the "uncontrolled conversions" problems. Bob At 5:10 PM -0500 3/3/07, Keith wrote: >Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > >Bob -- I think you hit the nail on the head. > >I was just coming to the same realization here. I knew that something funny >was going on because the same bytes always got "corrupted." > >I'm pretty sure its in the InputStreamReader() functionality where the >conversion junk is happening. > >Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > >I don't know if simply changing the cast is going to work. Since the >conversion is happening upstream (pun intended), I don't think my cast is >doing this. Also I think the compiler forced me to use the cast. -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mark at mdsh.com Sun Mar 4 11:01:33 2007 From: mark at mdsh.com (Mark Himsley) Date: Sun, 04 Mar 2007 18:01:33 +0000 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: <5C01AC72C200388815C04982@bedroom.mdsh.local> On 03 March 2007 14:38 -0500 Keith wrote: > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT > consistent. Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? It looks like you need to use DataInputStream and DataOutputStream. -- Mark Himsley From tjarvi at qbang.org Sun Mar 4 11:35:08 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 11:35:08 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" > > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > > * Line #21 - Not sure if you need a (TM) mark for > the term "Sun" > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > OK. I'm going through this today. Some groups ask if rxtx could be under their license also. I think this is a good example of why I resist multiple licenses and focus on why the current license may not be usable by them. The RXTX project is a convergence of hobby and commercial interests. I happen to do both right now. The problem with licensing is we have to stay on top of them as they change. Clearly, adding more licenses will not make this easier. I'm acting as the hobby person today. RXTX always favors the hobby people. But as we move forward, I'm going to need to bring this to lawyers at work and explain to them what is going on. Others here may have to do this also. I don't anticipate problems or unexpected changes. The goal is a consistant, comprehendable and usable license as close to what we have now as possible. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 14:52:10 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 14:52:10 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (1/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: I'm breaking this into two parts. I expect the second part will need more attention. Comments first, then the changed material below. On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > Thanks > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. OK. RXTX for consitent use. java should not be capitalized because it does not only mean Sun [TM] Java [TM]. An example of this not meaning Java is when people use RXTX with GCJ. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". There are not any contributors that are in all of RXTX yet but I did update the comment to try to reflect the current situation without making it a nightmare to maintain. I looked to see how the Linux kernel does it as a reference point. > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" The URL can be problematic. I have done so below with a time reference. GNU does not provide version information in their URLS. I picture this being a problem when the version 3 comes out. > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > This will be corrected when the copy is updated to the version linked below. ---------------- begin proposed material involved -------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. ----------------- end proposed material involved -------------------- I'll be looking at the linking issue again next. That should be all that remains other than including the 2.1 version. Let me know if you have problems with anything here. I do not want to dilute the material I post next with these housekeeping tasks. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 16:08:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 16:08:36 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: For those that are wondering what is going on here, this next bit is the meat of the changes. We agreed a long time ago to put this disclaimer in. We did a so so job. It was in rxtx 2.0, not well written, ... So some groups using rxtx that would like to ship rxtx so users don't need to download, install, go to the mail-list to find why it failed, ... Then their legal teams tell them section 5 paragraph 2 is a show stopper. That was never the intent. Now going through what remains... > and might need a (TM) suffix to make Sun happy. Added disclaimer at the ended 'all trademarks belong...' > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. OK. As you can see I was trying to adjust GNU text there for the LGPL. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. used dynamically linked terminology. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". I tried to address this more upfront with an intent statement. Let me know if you have problems with it. I also tried to make it a little more clear what was derived from the GNU solution by moving the link location closer to GNU's suggestion. > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > Thats the intent. Here is the combined fixes. Note that only the material in /*-- --*/ is being touched. The new GPL license is there but unmodified. ------------------------ begin proposed new license ------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. | | An executable that contains no derivative of any portion of RXTX, but | is designed to work with RXTX by being dynamically linked with it, | is considered a "work that uses the Library" subject to the terms and | conditions of the GNU Lesser General Public License. | | The following has been added to the RXTX License to remove | any confusion about linking to RXTX. We want to allow in part what | section 5, paragraph 2 of the LGPL does not permit in the special | case of linking over a controlled interface. The intent is to add a | Java Specification Request or standards body defined interface in the | future as another exception but one is not currently available. | | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface | | As a special exception, the copyright holders of RXTX give you | permission to link RXTX with independent modules that communicate with | RXTX solely through the Sun Microsytems CommAPI interface version 2, | regardless of the license terms of these independent modules, and to copy | and distribute the resulting combined work under terms of your choice, | provided that every copy of the combined work is accompanied by a complete | copy of the source code of RXTX (the version of RXTX used to produce the | combined work), being distributed under the terms of the GNU Lesser General | Public License plus this exception. An independent module is a | module which is not derived from or based on RXTX. | | Note that people who make modified versions of RXTX are not obligated | to grant this special exception for their modified versions; it is | their choice whether to do so. The GNU Lesser General Public License | gives permission to release a modified version without this exception; this | exception also makes it possible to release a modified version which | carries forward this exception. | | You should have received a copy of the GNU Lesser General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA | All trademarks belong to their respective owners. --------------------------------------------------------------------------*/ The original GNU Lesser General Public License Follows. GNU LESSER GENERAL PUBLIC LICENSE Version 2.1, February 1999 Copyright (C) 1991, 1999 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. [This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence the version number 2.1.] Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This license, the Lesser General Public License, applies to some specially designated software packages--typically libraries--of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below. When we speak of free software, we are referring to freedom of use, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish); that you receive source code or can get it if you want it; that you can change the software and use pieces of it in new free programs; and that you are informed that you can do these things. To protect your rights, we need to make restrictions that forbid distributors to deny you these rights or to ask you to surrender these rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library or if you modify it. For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights. We protect your rights with a two-step method: (1) we copyright the library, and (2) we offer you this license, which gives you legal permission to copy, distribute and/or modify the library. To protect each distributor, we want to make it very clear that there is no warranty for the free library. Also, if the library is modified by someone else and passed on, the recipients should know that what they have is not the original version, so that the original author's reputation will not be affected by problems that might be introduced by others. Finally, software patents pose a constant threat to the existence of any free program. We wish to make sure that a company cannot effectively restrict the users of a free program by obtaining a restrictive license from a patent holder. Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license. Most GNU software, including some libraries, is covered by the ordinary GNU General Public License. This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs. When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library. We call this license the "Lesser" General Public License because it does Less to protect the user's freedom than the ordinary General Public License. It also provides other free software developers Less of an advantage over competing non-free programs. These disadvantages are the reason we use the ordinary General Public License for many libraries. However, the Lesser license provides advantages in certain special circumstances. For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License. In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software. For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU operating system, as well as its variant, the GNU/Linux operating system. Although the Lesser General Public License is Less protective of the users' freedom, it does ensure that the user of a program that is linked with the Library has the freedom and the wherewithal to run that program using a modified version of the Library. The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, whereas the latter must be combined with the library in order to run. GNU LESSER GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License Agreement applies to any software library or other program which contains a notice placed by the copyright holder or other authorized party saying it may be distributed under the terms of this Lesser General Public License (also called "this License"). Each licensee is addressed as "you". A "library" means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables. The "Library", below, refers to any such software library or work which has been distributed under these terms. A "work based on the Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term "modification".) "Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library. Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does. 1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) The modified work must itself be a software library. b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change. c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License. d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful. (For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library. In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. 4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange. If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code. 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables. When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law. If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.) Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself. 6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications. You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things: a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.) b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. c) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution. d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place. e) Verify that the user has already received a copy of these materials or that you have already sent this user a copy. For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute. 7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things: a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above. b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work. 8. You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 9. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Library (or any work based on the Library), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Library or works based on it. 10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties with this License. 11. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply, and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 12. If the distribution and/or use of the Library is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Library under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 13. The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation. 14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Libraries If you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the ordinary General Public License). To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Also add information on how to contact you by electronic and paper mail. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the library, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the library `Frob' (a library for tweaking knobs) written by James Random Hacker. , 1 April 1990 Ty Coon, President of Vice That's all there is to it! ------------------------ end of proposed license ------------------ -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sun Mar 4 16:26:04 2007 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 04 Mar 2007 17:26:04 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <45EB558C.3010609@cox.net> Bob Jacobsen wrote: > Because of this and similar problems, JMRI does all it's serial IO > using +only+ byte values. It's a but of a pain, as Java wants to go > to char and int types a little too aggressively, but it does solve > the "uncontrolled conversions" problems. Anytime that you are reading bytes of data that is not printable, unicode text, in Java, you really need to stay away from the Readers. Use input stream only, or you will see unicode valued byte groups converted to unicode "char" values. Gregg Wonderly From joachim at buechse.de Mon Mar 5 04:23:48 2007 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 5 Mar 2007 12:23:48 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> The behaviour is exactly what you asked for in you code. is = new BufferedReader(new InputStreamReader(port.getInputStream())); Readers return Text (ie unicode chars) not bytes. You instantiate the InputStreamReader without saying which charset you want, which means "platform default". As this is on Windows, it will convert Windows characters to equivalent unicode characters. If you want to read bytes, read bytes not Text. Reading bytes is done with InputStream and BufferedInputStream. BTW: The InputStream and Reader methods that read arrays are not guarenteed to fill up the array. You always have to check what you really got, and advance your index accordingly. A typical "read up to 32k" method looks like this: InputStream is= ... // -- determine the max buffer size int len= is.available(); if (len == 0) { len= 32 * 1024; } // -- read all available data byte[] buffer= new byte[len]; int pos= 0; int read; do { read= is.read(buffer, pos, buffer.length - pos); pos= pos + read; } while (read != -1 && pos < buffer.length); Best regards, Joachim --- Joachim B?chse Phone: +41 44 500 2604 Buechse Consulting Hadlaubsteig 2 CH-8006 Z?rich On 03.03.2007, at 23:10, Keith wrote: > Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > > Bob -- I think you hit the nail on the head. > > I was just coming to the same realization here. I knew that > something funny > was going on because the same bytes always got "corrupted." > > I'm pretty sure its in the InputStreamReader() functionality where the > conversion junk is happening. > > Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > > I don't know if simply changing the cast is going to work. Since the > conversion is happening upstream (pun intended), I don't think my > cast is > doing this. Also I think the compiler forced me to use the cast. > > I'm still playing around, and I'll report back once I nail it down. > > Thanks!! > > Keith > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Mon Mar 5 07:25:46 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 05 Mar 2007 08:25:46 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> Message-ID: <45EC286A.8060608@cox.net> Joachim Buechse wrote: > BTW: The InputStream and Reader methods that read arrays are not > guarenteed to fill up the array. You always have to check what you > really got, and advance your index accordingly. A typical "read up to > 32k" method looks like this: > > InputStream is= ... > // -- determine the max buffer size > int len= is.available(); > if (len == 0) { > len= 32 * 1024; > } > // -- read all available data > byte[] buffer= new byte[len]; > int pos= 0; > int read; > do { > read= is.read(buffer, pos, buffer.length - pos); > pos= pos + read; > } while (read != -1 && pos < buffer.length); > My preferred structure is. byte arr[ len ]; int cnt; int off = 0; while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { off += cnt; } This keeps you from adding -1 to pos when the read returns -1. It also skips out when the read is 0 bytes which, is not a described EOF in InputStream java docs, but is a condition I want to be aware of. Gregg Wonderly From joachim at buechse.de Tue Mar 6 02:52:58 2007 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 6 Mar 2007 10:52:58 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <45EC286A.8060608@cox.net> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: The code I copied was from a file resource reader, it shouldn't really be applied to networking/external IO code. Mea culpa. However aborting when you get 0 from read is not always what you want either (you kind of indicated that already). Some unix java implementations will return 0 if the kernel read was aborted with EINTER, which is rarely the point where you want to abort your read - at least not without further checks. A "complete" solution always depends on the events you need to handle and the time the total read could take in reality. In some cases it's worth checking Thread.isInterrupted() in the loop, some code re-loops on 0 but only a limited number of times, some check a total timeout limit, etc... Best regards, Joachim On 05.03.2007, at 15:25, Gregg Wonderly wrote: > My preferred structure is. > > byte arr[ len ]; > int cnt; > int off = 0; > while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { > off += cnt; > } > > This keeps you from adding -1 to pos when the read returns -1. It > also skips > out when the read is 0 bytes which, is not a described EOF in > InputStream java > docs, but is a condition I want to be aware of. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Mar 6 14:47:44 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 Mar 2007 14:47:44 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: Just FYI, rxtx will usually not break out on EINTER. The code in the native library usually does something close to this: do { read(...) } while ( !done && errno==EINTR ); Obviously there is a little more involved but it will retry on EINTER if not done. On Tue, 6 Mar 2007, Joachim Buechse wrote: > The code I copied was from a file resource reader, it shouldn't > really be applied to networking/external IO code. Mea culpa. > > However aborting when you get 0 from read is not always what you want > either (you kind of indicated that already). Some unix java > implementations will return 0 if the kernel read was aborted with > EINTER, which is rarely the point where you want to abort your read - > at least not without further checks. A "complete" solution always > depends on the events you need to handle and the time the total read > could take in reality. In some cases it's worth checking > Thread.isInterrupted() in the loop, some code re-loops on 0 but only > a limited number of times, some check a total timeout limit, etc... > > Best regards, > Joachim > > On 05.03.2007, at 15:25, Gregg Wonderly wrote: >> My preferred structure is. >> >> byte arr[ len ]; >> int cnt; >> int off = 0; >> while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { >> off += cnt; >> } >> >> This keeps you from adding -1 to pos when the read returns -1. It >> also skips >> out when the read is 0 bytes which, is not a described EOF in >> InputStream java >> docs, but is a condition I want to be aware of. >> >> Gregg Wonderly >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 gjhanna at gmail.com Thu Mar 8 13:42:52 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Fri, 9 Mar 2007 09:42:52 +1300 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? Message-ID: I've just struck an issue using rxtx in a multi-threaded environment: If I have 3 threads trying to open *the same* comm-port I get a deadlock in CommPortIdentifier.open If I have just 2, it works fine - I get a PortInUseException which is nice and I can handle it. The 3 thread->deadlock thing is causing me issues. (Sample code below). This is from the java thread-dump Found one Java-level deadlock: ============================= "Thread-2": waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object ), which is held by "Thread-1" "Thread-1": waiting to lock monitor 0x0003e9cc (object 0x2450e108, a gnu.io.CommPortIdentifier), which is held by "Thread-2" Java stack information for the threads listed above: =================================================== "Thread-2": at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:329) - waiting to lock <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) "Thread-1": at java.lang.Object.wait(Native Method) - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) - locked <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) (Apart from this, rxtx is working fantastically for us). I'm thinking I'll have to implement some sort of locking mechanism that *doesn't* use java synchronization to prevent this situation. (Which doesn't sound like a good idea to me). Any ideas? Thanks, Greg Hanna ============= RXTXLockTest.java ======================================== import gnu.io.CommPort; import gnu.io.CommPortIdentifier; /** * @author Greg Hanna * Minimal code to create a deadlock with rxtx in multithreaded open */ public class RXTXLockTest { public static void main(String[] args) { try { CommPortIdentifier cpiCom1 = CommPortIdentifier.getPortIdentifier ("COM14"); OpenThread t1 = new OpenThread (" one ", cpiCom1); OpenThread t2 = new OpenThread (" two ", cpiCom1); OpenThread t3 = new OpenThread (" 003 ", cpiCom1); t1.start(); t2.start(); t3.start(); // comment this out and it runs with (expected) PortInUseException } catch (Exception e) { e.printStackTrace(); } } } class OpenThread extends Thread { String name; CommPortIdentifier cpi; CommPort cp; public OpenThread (String name, CommPortIdentifier cpi) { this.name = name; this.cpi = cpi; System.out.println (System.currentTimeMillis() + name + " thread created"); } public void run () { try { System.out.println (System.currentTimeMillis() + name + " opening"); cp = cpi.open(name, 2000); System.out.println (System.currentTimeMillis() + name + " opened - sleeping"); sleep (2000); // do the serial comms with the device. System.out.println (System.currentTimeMillis() + name + " slept - closing"); cp.close(); System.out.println (System.currentTimeMillis() + name + " closed - exiting"); } catch (Exception e) { System.out.println ("Error in thread: " + name ); e.printStackTrace(); } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070308/d9a163c5/attachment-0009.html From eu259473 at tele2.it Fri Mar 9 02:46:20 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 09 Mar 2007 10:46:20 +0100 Subject: [Rxtx] rxtx: tru64 unix make fails Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070309/3b654523/attachment-0009.html From lyon at docjava.com Fri Mar 9 03:58:32 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 Mar 2007 05:58:32 -0500 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi All, The deadlock issue is one that I have been thinking about for some time now. It seems to me that we need a resource manager that enables assignment to a known process. The one thing that seems important about serial ports is that two applications should not use the same serial port at the same time. When this happens, it throws an exception. OK. The exception is a response to a lock condition that arises from an unavailable resource. An abstract implementation (not born of native methods) might assign a serial port to an application, until the application releases it (or is forced to release it by some kill mechanism). Some resources (like a registry) can be reused. But others, like the serial port, cannot. In the case of the serial port, we would like, I think, to have the flyweight design pattern without sharing and with object assignment tracking. A means of breaking deadlock (like a leasing mechanism) seems very useful, to me. My guess is that we can serialize the state of the Parametric Singleton Pattern (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) into the Preferences of the System. Preferences.systemRoot() might help with that. When a resource is checked out, the lease time and owner are listed. A thread that does this can be killed, but applications outside of Java are problematic. There is a compelling problem here. It is not just serial ports. Sound cards, cameras, microphones, files, tape drives, etc. All are consumed resources that are assigned to an application (or user) and deprive other applications, or users, from use. What, if anything, should we do? At present we throw PortInUseExceptions. Is that it? Can we do better? OK, the port is in use. Now what? Do I have to be root to go remove lock files and kill applications? Is there a better way? Thanks! - Doug >I've just struck an issue using rxtx in a multi-threaded environment: > >If I have 3 threads trying to open *the same* >comm-port I get a deadlock in >CommPortIdentifier.open >If I have just 2, it works fine - I get a >PortInUseException which is nice and I can >handle it. > >The 3 thread->deadlock thing is causing me issues. >(Sample code below). > >This is from the java thread-dump > >Found one Java-level deadlock: >============================= >"Thread-2": > waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), > which is held by "Thread-1" >"Thread-1": > waiting to lock monitor 0x0003e9cc (object >0x2450e108, a gnu.io.CommPortIdentifier ), > which is held by "Thread-2" > >Java stack information for the threads listed above: >=================================================== >"Thread-2": > at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) > - waiting to lock <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) >"Thread-1": > at java.lang.Object.wait(Native Method) > - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) > - locked <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) > > >(Apart from this, rxtx is working fantastically for us). > >I'm thinking I'll have to implement some sort of >locking mechanism that *doesn't* use java >synchronization to prevent this situation. >(Which doesn't sound like a good idea to me). > >Any ideas? > >Thanks, > >Greg Hanna > >============= RXTXLockTest.java ======================================== > >import gnu.io.CommPort; >import gnu.io.CommPortIdentifier; > >/** > * @author Greg Hanna > * Minimal code to create a deadlock with rxtx in multithreaded open > */ >public class RXTXLockTest { > ? > ?public static void main(String[] args) { > ?try { > ?CommPortIdentifier cpiCom1 = >CommPortIdentifier.getPortIdentifier ("COM14"); > ?OpenThread t1 = new OpenThread (" one ", cpiCom1); > ?OpenThread t2 = new OpenThread (" two ", cpiCom1); > ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); > ?t1.start(); > ?t2.start(); > ?t3.start(); // comment this out >and it runs with (expected) PortInUseException > ?} catch (Exception e) { > ?e.printStackTrace(); > ?} > ?} >} > >class OpenThread extends Thread { > ?String name; > ?CommPortIdentifier cpi; > ?CommPort cp; > ?public OpenThread (String name, CommPortIdentifier cpi) { > ? this.name = name; > ?this.cpi = cpi; > ?System.out.println >(System.currentTimeMillis() + name + " thread >created"); > ?} > ?public void run () { > ?try { > ?System.out.println >(System.currentTimeMillis() + name + " opening"); > ?cp = cpi.open(name, 2000); > ?System.out.println >(System.currentTimeMillis() + name + " opened - >sleeping"); > ?sleep (2000); // do the serial comms with the device. > ?System.out.println >(System.currentTimeMillis() + name + " slept - >closing"); > ?cp.close(); > ?System.out.println >(System.currentTimeMillis() + name + " closed - >exiting"); > ?} catch (Exception e) { > System.out.println ("Error in thread: " + name ); > ?e.printStackTrace(); > ?} > ?} >} > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Mar 9 06:37:45 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 Mar 2007 06:37:45 -0700 (MST) Subject: [Rxtx] rxtx: tru64 unix make fails In-Reply-To: References: Message-ID: On Fri, 9 Mar 2007, "Giuseppe Marchese" wrote: > Sorry for delay. > ? > This is log for ./configure and make > error. > ? > thanks for attention > ? > Make: '%.java,$(TOP)/$(CLASSDEST)/%.class,$(wildcard $(SPATH)/*.java)': extra chars.? > Stop. > Hi Giuseppe You need to use GNU make with the Makefile. I suspect the tru64 make is not happy with those rules. > configure: exit 0 Looks like configure is fairly happy. From tjarvi at qbang.org Sat Mar 10 07:43:51 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 07:43:51 -0700 (MST) Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi Doug I have very little time to look into this further but what we could do is open up an rxtx 3 devel branch in which a proof of concept could be worked on. It could be the proof of concept for a JSR others including Sun could look at/work on or parts of it could be recycled in a JSR. I'm working very hard on rxtx right now but it does not show. I'm looking at win64, mac intel/ppc, usb bluetooth and usb serial dongles. Some are going to be more tested than others but they are all on the plate. I'll be pushing all the fixes upstream when they are done. So I'm very busy in 2.1 but we could open a new branch. On Fri, 9 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > The deadlock issue is one that I have been thinking about > for some time now. > It seems to me that we need a resource manager that enables assignment > to a known process. > > The one thing that seems important about serial > ports is that two applications should not use the > same serial port at the same time. When this > happens, it throws an exception. > OK. > > The exception is a response to a lock condition that > arises from an unavailable resource. > > An abstract implementation (not born of native methods) might > assign a serial port to an application, until the > application releases it (or is forced to release > it by some kill mechanism). > > Some resources (like a registry) can be reused. > But others, like the serial port, > cannot. > > In the case of the serial port, we would like, I think, to > have the flyweight design pattern > without sharing and with object assignment tracking. > A means of breaking deadlock (like a leasing > mechanism) seems very useful, to me. > > My guess is that we can serialize the state of the Parametric Singleton Pattern > (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) > into the Preferences of the System. Preferences.systemRoot() might help > with that. When a resource is checked out, the lease time and owner are > listed. A thread that does this can be killed, but applications outside of Java > are problematic. > > There is a compelling problem here. It is not just serial ports. > Sound cards, cameras, microphones, files, tape drives, etc. All are consumed > resources that are assigned to an application (or > user) and deprive other applications, > or users, from use. > > What, if anything, should we do? At present we throw PortInUseExceptions. > Is that it? > Can we do better? > OK, the port is in use. Now what? > Do I have to be root to go remove lock files and kill applications? > Is there a better way? > > Thanks! > - Doug > >> I've just struck an issue using rxtx in a multi-threaded environment: >> >> If I have 3 threads trying to open *the same* >> comm-port I get a deadlock in >> CommPortIdentifier.open >> If I have just 2, it works fine - I get a >> PortInUseException which is nice and I can >> handle it. >> >> The 3 thread->deadlock thing is causing me issues. >> (Sample code below). >> >> This is from the java thread-dump >> >> Found one Java-level deadlock: >> ============================= >> "Thread-2": >> waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), >> which is held by "Thread-1" >> "Thread-1": >> waiting to lock monitor 0x0003e9cc (object >> 0x2450e108, a gnu.io.CommPortIdentifier ), >> which is held by "Thread-2" >> >> Java stack information for the threads listed above: >> =================================================== >> "Thread-2": >> at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) >> - waiting to lock <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> "Thread-1": >> at java.lang.Object.wait(Native Method) >> - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) >> - locked <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> >> >> (Apart from this, rxtx is working fantastically for us). >> >> I'm thinking I'll have to implement some sort of >> locking mechanism that *doesn't* use java >> synchronization to prevent this situation. >> (Which doesn't sound like a good idea to me). >> >> Any ideas? >> >> Thanks, >> >> Greg Hanna >> >> ============= RXTXLockTest.java ======================================== >> >> import gnu.io.CommPort; >> import gnu.io.CommPortIdentifier; >> >> /** >> * @author Greg Hanna >> * Minimal code to create a deadlock with rxtx in multithreaded open >> */ >> public class RXTXLockTest { >> ? >> ?public static void main(String[] args) { >> ?try { >> ?CommPortIdentifier cpiCom1 = >> CommPortIdentifier.getPortIdentifier ("COM14"); >> ?OpenThread t1 = new OpenThread (" one ", cpiCom1); >> ?OpenThread t2 = new OpenThread (" two ", cpiCom1); >> ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); >> ?t1.start(); >> ?t2.start(); >> ?t3.start(); // comment this out >> and it runs with (expected) PortInUseException >> ?} catch (Exception e) { >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> class OpenThread extends Thread { >> ?String name; >> ?CommPortIdentifier cpi; >> ?CommPort cp; >> ?public OpenThread (String name, CommPortIdentifier cpi) { >> ? this.name = name; >> ?this.cpi = cpi; >> ?System.out.println >> (System.currentTimeMillis() + name + " thread >> created"); >> ?} >> ?public void run () { >> ?try { >> ?System.out.println >> (System.currentTimeMillis() + name + " opening"); >> ?cp = cpi.open(name, 2000); >> ?System.out.println >> (System.currentTimeMillis() + name + " opened - >> sleeping"); >> ?sleep (2000); // do the serial comms with the device. >> ?System.out.println >> (System.currentTimeMillis() + name + " slept - >> closing"); >> ?cp.close(); >> ?System.out.println >> (System.currentTimeMillis() + name + " closed - >> exiting"); >> ?} catch (Exception e) { >> System.out.println ("Error in thread: " + name ); >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 mm at UDel.Edu Sat Mar 10 14:48:32 2007 From: mm at UDel.Edu (Mike Markowski) Date: Sat, 10 Mar 2007 16:48:32 -0500 Subject: [Rxtx] rxtx and Sun's comm api Message-ID: <45F327B0.2060004@udel.edu> Hi all, I joined the list a few days ago and apologize for what is likely a frequently asked question, though I haven't yet found it anywhere. I learned about rxtx.org through the readme on Sun's version 2 of their comms api. They give recommendations in that readme regarding how a better comms api should be written. Is this the aim of rxtx.org? I wrote an app on my linux box using the Sun comms api (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the fact that only linux and Solaris are supported. So I'm glad to find rxtx.org and am just reading up on how make the conversion so Windows users will be able to run the program as well. At the same time I'm just curious if rxtx.org and Sun are both heading in the same direction. Thanks for any background or historical info. Feel free to point me to any www pages if my googling has just completely missed the target! Thanks again, Mike From tjarvi at qbang.org Sat Mar 10 15:35:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 15:35:25 -0700 (MST) Subject: [Rxtx] rxtx and Sun's comm api In-Reply-To: <45F327B0.2060004@udel.edu> References: <45F327B0.2060004@udel.edu> Message-ID: On Sat, 10 Mar 2007, Mike Markowski wrote: > Hi all, > > I joined the list a few days ago and apologize for what is likely a > frequently asked question, though I haven't yet found it anywhere. I > learned about rxtx.org through the readme on Sun's version 2 of their > comms api. They give recommendations in that readme regarding how a > better comms api should be written. Is this the aim of rxtx.org? > > I wrote an app on my linux box using the Sun comms api > (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the > fact that only linux and Solaris are supported. So I'm glad to find > rxtx.org and am just reading up on how make the conversion so Windows > users will be able to run the program as well. At the same time I'm > just curious if rxtx.org and Sun are both heading in the same direction. > > Thanks for any background or historical info. Feel free to point me to > any www pages if my googling has just completely missed the target! > I do not have any news (good or bad) concerning RXTX and Sun working together but perhaps others here do. The main goal of RXTX is to expose POSIX termios interfaces to java users. The future support of javax.comm is questionable. We do not have resources for everything. gnu.io (RXTX 2.1) will be supported going forward and functions the same as CommAPI 2.0. If you have control of the source code you are working with, I would not advise using CommAPI 2.0 javax.comm. We do support CommAPI 2.0 javax.comm for older applications but I do not think that will last much longer for practical reasons. The download interest in CommAPI 2.0 javax.comm support is becomming negligible on this end. There has been discussion of a JSR effort but I do not know of any status change since it was mentioned. One problem with a JSR is that even a light weight process is going to be difficult for RXTX at this time. Maybe that will change in the future but then again it may not. For now, we are just going forward 'as is' in rxtx 2.1 with package gnu.io while trying as a secondary effort to backport the changes to rxtx 2.0 for javax.comm support for users that do not have a choice. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Mar 11 07:19:40 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 11 Mar 2007 08:19:40 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: Hi All, I have been a proponent of a JSR that makes use of RXTX. I have executed the proper agreements with Sun. At this point we are in the: Early Draft Review of Draft Specifications Stage. The best thing to do is to enter the quiet period and create a specification. The question of exactly how we, as a group, want to approach this problem, remains open. Typically, we should have both a specification and a reference implementation. Thus, it would be to our best advantage to have a nice, stable, cross platform RXTX distro that adheres to the groups specification. Now, from a specification standpoint, my personal view on the matter is that we create a series of interfaces, with nice documentation (or at least javadoc). Is this a good idea? Should we have a pure interface specification for the communication API? There are several issues, in my mind, which still weigh on us. Hot-pluggable dongles, long discovery process on pop-up ports, lack of uniformity on device names, lack of uniformity on locking, a precise understanding of how the SerialPortResourceManager works (or even if we should have one). The more questions we answer in our reference implementation, the better our specification will get. RXTX is a good working prototype, but, I don't know if that is what we want to use for a specification. Here is what I have for a CommPortInterface: */ public interface CommPortInterface { /** * @return a string representation of this port. */ String toString(); /** * Gets the name of the communications port. This name should correspond to * something the user can identify, like the label on the hardware. * @return name of the port */ String getName(); /** * @return an input stream that can be used to read data from the * communications port. If the port doesn't support reading data, this * method returns null. *

* The blocking behaviour of this input stream depends on the threshold * and timeout values, as shown below for a read buffer size of n * bytes: * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ThresholdTimeoutBlocking behaviour
StateValueStateValue
disableddisabledblock until data is available
enabledm bytesdisabledblock until min(m, n) bytes are available
disabledenabledt msblock for t ms or until data is available
enabledm bytesenabledt msblock for t ms or until min(m, n) bytes are * available
* @throws java.io.IOException */ InputStream getInputStream() throws IOException; /** * @return an output stream that can be used to send data to the * communications port. If the port doesn't support sending data, this * method returns null. * @throws java.io.IOException */ OutputStream getOutputStream() throws IOException; /** * Closes this communications port. * All PortOwnershipListeners will be? * notified of this change of ownership. Further method calls on this? * object will throw IllegalStateException. Further calls on the? * associated InputStream or OutputStream will throw IOException. *

* Close does not block. Undelivered data is discarded. Blocked read and? * write operations are aborted if the underlying operating systems? * supports an IO abort mechanism. To await the delivery of undelivered? * data call OutputStream.flush() or OutputStream.close() before calling? * Port.close(). */ void close(); /** * Enables receive threshold. * When the specified threshold number of bytes are retrieved, read will * return immediately. * * @param thresh the number of bytes in the input buffer * @throws gnu.io.UnsupportedCommOperationException * if receive threshold is * not supported by the driver * @see #disableReceiveThreshold */ void enableReceiveThreshold(int thresh) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive threshold. * * @see #enableReceiveThreshold */ void disableReceiveThreshold(); /** * @return true if receive threshold is enabled. * * @see #enableReceiveThreshold */ boolean isReceiveThresholdEnabled(); /** * @return the receive threshold value. If receive threshold is diabled * or not supported, this value is meaningless. * * @see #enableReceiveThreshold */ int getReceiveThreshold(); /** * Enables receive timeout. * When the specified number of milliseconds have elapsed, read will * return immediately. * * @param rcvTimeout the number of milliseconds to block for * @throws gnu.io.UnsupportedCommOperationException * if receive timeout is * not supported by the driver * @see #disableReceiveTimeout */ void enableReceiveTimeout(int rcvTimeout) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive timeout. * * @see #enableReceiveTimeout */ void disableReceiveTimeout(); /** * @return true if receive timeout is enabled. * * @see #enableReceiveTimeout */ boolean isReceiveTimeoutEnabled(); /** * @return the receive timeout value. If receive timeout is diabled * or not supported, this value is meaningless. * * @see #enableReceiveTimeout */ int getReceiveTimeout(); /** * Enables receive framing. * The supplied byte value in the input suggests the end of the received * frame, and read returns immediately. Only the low 8 bits of the * supplied value are significant. * * @param framingByte the frame delimiter * @throws gnu.io.UnsupportedCommOperationException * if receive framing is * not supported by the driver * @see #disableReceiveFraming */ void enableReceiveFraming(int framingByte) throws UnsupportedCommOperationException; /** * Disables receive framing. * * @see #enableReceiveFraming */ void disableReceiveFraming(); /** * @return true if receive framing is enabled. * * @see #enableReceiveFraming */ boolean isReceiveFramingEnabled(); /** * @return true if receive framing byte. If receive framing is diabled * or not supported, this value is meaningless. * * @see #enableReceiveFraming */ int getReceiveFramingByte(); /** * Sets the input buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setInputBufferSize(int size); /** * @return the input buffer size. * The driver may choose not to report correct values. */ int getInputBufferSize(); /** * Sets the output buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setOutputBufferSize(int size); /** * @return the output buffer size. * The driver may choose not to report correct values. */ int getOutputBufferSize(); } What do you think of that? Note the wishy washy nature of the spec: The driver may choose to ignore this method. Is that good enough for us? Thanks! - Doug From ra85551 at gmail.com Sun Mar 11 08:44:45 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Sun, 11 Mar 2007 17:44:45 +0300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hello, world! I am writing application that communicates with modem via AT commands. My OS is Linux Kubuntu Feisty Herd, to ensure that my application will run properly under Windows XP I installed VMWare server. When I tried to send AT command and evaluate modem answer under WinXP @ VMWare server, I actually didn't receive anything. I think that VM settings are right, because I do can communicate with modem by using standard HyperTerminall as well as I can do on native Windows. So, why RXTX doesn't work under VM, but works under Linux and pure Windows XP (i tested it there) well? The send/receive method code follows. private String sendATCommand(String command, final String waitFor, final boolean isRegex, boolean isAddCRLF, long timeout) throws BeaconConnectException { final long POLL_PERIOD = 100; final int BUFFER_SIZE = 512; final byte[] buffer = new byte[BUFFER_SIZE]; final InputStream serialInput; final OutputStream serialOutput; try { serialInput = serialPort.getInputStream(); if (command != null) { serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } } catch (IOException e) { throw new MyException("serial I/O error"); } TimerTask task = new TimerTask() { int offset = 0; int bytesRead; public synchronized void run() { try { if (serialInput.available() > 0) { bytesRead = serialInput.read(buffer, offset, BUFFER_SIZE - offset); } else { return; } } catch (IOException e) { // do nothing - maybe next time we'll read something } offset += bytesRead; if (waitFor != null) { String temporary = new String(buffer, 0, offset).trim(); if (isRegex && temporary.matches(waitFor) || temporary.contains(waitFor)) { cancel(); notify(); } } } }; Timer timer = new Timer(); timer.schedule(task, POLL_PERIOD, POLL_PERIOD); synchronized (task) { try { task.wait(timeout); task.cancel(); } catch (InterruptedException e) { } } //Cut off leading and trailing CRs, LFs and zeroes String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); System.out.println(response); return response; } -- Pavel Parkhomenko From tjarvi at qbang.org Sun Mar 11 11:48:22 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:48:22 -0600 (MDT) Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: On Sun, 11 Mar 2007, Pavel Parkhomenko wrote: > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. > > private String sendATCommand(String command, final String waitFor, > final boolean isRegex, boolean isAddCRLF, long timeout) > throws BeaconConnectException > { > final long POLL_PERIOD = 100; > final int BUFFER_SIZE = 512; > final byte[] buffer = new byte[BUFFER_SIZE]; > final InputStream serialInput; > final OutputStream serialOutput; > try > { > serialInput = serialPort.getInputStream(); > if (command != null) > { > serialOutput = serialPort.getOutputStream(); > if (isAddCRLF) > { > command += "\r\n"; > } > System.out.println(command); > serialOutput.write(command.getBytes()); > } > } > catch (IOException e) > { > throw new MyException("serial I/O error"); > } > > TimerTask task = new TimerTask() > { > int offset = 0; > int bytesRead; > public synchronized void run() > { > try > { > if (serialInput.available() > 0) > { > bytesRead = serialInput.read(buffer, offset, > BUFFER_SIZE - offset); > } > else > { > return; > } > } > catch (IOException e) > { > // do nothing - maybe next time we'll read something > } > offset += bytesRead; > if (waitFor != null) > { > String temporary = new String(buffer, 0, offset).trim(); > if (isRegex && temporary.matches(waitFor) || > temporary.contains(waitFor)) > { > cancel(); > notify(); > } > } > } > }; > > Timer timer = new Timer(); > timer.schedule(task, POLL_PERIOD, POLL_PERIOD); > synchronized (task) { > try > { > task.wait(timeout); > task.cancel(); > } > catch (InterruptedException e) > { > } > } > //Cut off leading and trailing CRs, LFs and zeroes > String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); > System.out.println(response); > return response; > } > > > Hi Pavel VMWare should not be a problem. I've used it in the past - though not with a modem. Make sure nothing else is using the modem. Then look in the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an example that should work. Note that modems could care less what OS is on top. If you are trying to match new lines to the OS and sending it to the mode for AT commands, thats probably a mistake. Also it would not hurt to print out the individual bytes that you are sending to make sure they did not get mangled along the path. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 11:55:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:55:48 -0600 (MDT) Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: On Sun, 11 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > I have been a proponent of a JSR that makes > use of RXTX. I have executed the proper agreements with Sun. > > At this point we are in the: > Early Draft Review of Draft Specifications Stage. > > The best thing to do is to enter the quiet period and create > a specification. The question of exactly how we, as a group, > want to approach this problem, remains open. > > Typically, we should have both a specification and a reference > implementation. Thus, it would be to our best advantage to have > a nice, stable, cross platform RXTX distro that adheres to the > groups specification. > > Now, from a specification standpoint, my personal view on the matter is > that we create a series of interfaces, with nice documentation (or at least > javadoc). > > Is this a good idea? Should we have a pure interface specification for > the communication API? > > There are several issues, in my mind, which still weigh on us. > Hot-pluggable dongles, long discovery process on pop-up ports, > lack of uniformity on device names, lack of uniformity on locking, > a precise understanding of how the SerialPortResourceManager > works (or even if we should have one). > > The more questions we answer in our reference implementation, the > better our specification will get. RXTX is a good working prototype, > but, I don't know if that is what we want to use for a specification. > > Here is what I have for a CommPortInterface: > */ > public interface CommPortInterface { Hi Doug, I can start going through the method interfaces later this week and giving feedback. I would suggest that the JSR should not be too generic in nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel drivers that intend to look like EIA232 ports at the kernel driver level. some ideas: EIA232PortInterface TermiosInterface SerialPortInterface Something that differentiates this from thing like USB, I2C, ... which should not have to deal with legacy serial claiming to be the comm api. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 12:52:19 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 12:52:19 -0600 (MDT) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: No news is good news with these posts. I'll start the process of pinging legal a week from Monday on my end if nobody has objections to the proposal. I just want to make sure everyone has time to raise objections. Obviously, anyone can fork from a previous version if they don't like the new license. I suspect we can avoid that though. On Sun, 4 Mar 2007, Trent Jarvi wrote: > > For those that are wondering what is going on here, this > next bit is the meat of the changes. We agreed a long time > ago to put this disclaimer in. We did a so so job. It was > in rxtx 2.0, not well written, ... So some groups using > rxtx that would like to ship rxtx so users don't need to > download, install, go to the mail-list to find why it failed, > ... Then their legal teams tell them section 5 paragraph 2 > is a show stopper. > > That was never the intent. > > > Now going through what remains... > >> and might need a (TM) suffix to make Sun happy. > > Added disclaimer at the ended 'all trademarks belong...' > >> * Line #15ff - static vs. dynamic linking - you did >> not transcribe the text from the "controlled >> interface exception" when writing this text - and >> this was good so, because these terms originally >> refer to the GPL rather than the LGPL. I think though, >> that these 4 lines are the most important ones and >> should thus be really really clear. I hope that I >> meet your original intent with the following >> suggestions: >> 1.) Instead of "A program.." it would be better to >> say "An exectuable.." in order to be closer to >> the LGPL text. > > OK. As you can see I was trying to adjust GNU text there > for the LGPL. > >> 2.) It would be better to say .. "by being dynamically >> linked with it" to clearly indicate that dynamic >> linking is meant. The matter of compilation is >> already covered by the LGPL so mentioning it again >> just leads to confusion. > > used dynamically linked terminology. > >> 3.) It would be better to say .. "is considered a >> work that uses the library in contrast to section >> 5 of the LGPL, so the terms of the LGPL do not >> apply to the resulting executable". > > I tried to address this more upfront with an intent statement. > Let me know if you have problems with it. I also tried to > make it a little more clear what was derived from the GNU > solution by moving the link location closer to GNU's suggestion. > >> >> Note that LGPL section 5 says: ..."is called a >> "work that uses the Library". Such a work, in isolation, >> is not a derivative work of the Library, and therefore >> falls outside the scope of this License." >> The next paragraph of the LGPL is exactly the problematic >> one that I hope is clarified by the exception terms you >> give. >> > > Thats the intent. Here is the combined fixes. Note that only the > material in /*-- --*/ is being touched. The new GPL license is > there but unmodified. > > > ------------------------ begin proposed new license ------------------- > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Lesser General Public > | License as published by the Free Software Foundation; either > | version 2.1 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Lesser General Public License for more details. > | > | An executable that contains no derivative of any portion of RXTX, but > | is designed to work with RXTX by being dynamically linked with it, > | is considered a "work that uses the Library" subject to the terms and > | conditions of the GNU Lesser General Public License. > | > | The following has been added to the RXTX License to remove > | any confusion about linking to RXTX. We want to allow in part what > | section 5, paragraph 2 of the LGPL does not permit in the special > | case of linking over a controlled interface. The intent is to add a > | Java Specification Request or standards body defined interface in the > | future as another exception but one is not currently available. > | > | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface > | > | As a special exception, the copyright holders of RXTX give you > | permission to link RXTX with independent modules that communicate with > | RXTX solely through the Sun Microsytems CommAPI interface version 2, > | regardless of the license terms of these independent modules, and to copy > | and distribute the resulting combined work under terms of your choice, > | provided that every copy of the combined work is accompanied by a complete > | copy of the source code of RXTX (the version of RXTX used to produce the > | combined work), being distributed under the terms of the GNU Lesser General > | Public License plus this exception. An independent module is a > | module which is not derived from or based on RXTX. > | > | Note that people who make modified versions of RXTX are not obligated > | to grant this special exception for their modified versions; it is > | their choice whether to do so. The GNU Lesser General Public License > | gives permission to release a modified version without this exception; this > | exception also makes it possible to release a modified version which > | carries forward this exception. > | > | You should have received a copy of the GNU Lesser General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > | All trademarks belong to their respective owners. > --------------------------------------------------------------------------*/ > > The original GNU Lesser General Public License Follows. > > > GNU LESSER GENERAL PUBLIC LICENSE > Version 2.1, February 1999 > > Copyright (C) 1991, 1999 Free Software Foundation, Inc. > 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > Everyone is permitted to copy and distribute verbatim copies > of this license document, but changing it is not allowed. > > [This is the first released version of the Lesser GPL. It also counts > as the successor of the GNU Library Public License, version 2, hence > the version number 2.1.] > > Preamble > > The licenses for most software are designed to take away your > freedom to share and change it. By contrast, the GNU General Public > Licenses are intended to guarantee your freedom to share and change > free software--to make sure the software is free for all its users. > > This license, the Lesser General Public License, applies to some > specially designated software packages--typically libraries--of the > Free Software Foundation and other authors who decide to use it. You > can use it too, but we suggest you first think carefully about whether > this license or the ordinary General Public License is the better > strategy to use in any particular case, based on the explanations below. > > When we speak of free software, we are referring to freedom of use, > not price. Our General Public Licenses are designed to make sure that > you have the freedom to distribute copies of free software (and charge > for this service if you wish); that you receive source code or can get > it if you want it; that you can change the software and use pieces of > it in new free programs; and that you are informed that you can do > these things. > > To protect your rights, we need to make restrictions that forbid > distributors to deny you these rights or to ask you to surrender these > rights. These restrictions translate to certain responsibilities for > you if you distribute copies of the library or if you modify it. > > For example, if you distribute copies of the library, whether gratis > or for a fee, you must give the recipients all the rights that we gave > you. You must make sure that they, too, receive or can get the source > code. If you link other code with the library, you must provide > complete object files to the recipients, so that they can relink them > with the library after making changes to the library and recompiling > it. And you must show them these terms so they know their rights. > > We protect your rights with a two-step method: (1) we copyright the > library, and (2) we offer you this license, which gives you legal > permission to copy, distribute and/or modify the library. > > To protect each distributor, we want to make it very clear that > there is no warranty for the free library. Also, if the library is > modified by someone else and passed on, the recipients should know > that what they have is not the original version, so that the original > author's reputation will not be affected by problems that might be > introduced by others. > > Finally, software patents pose a constant threat to the existence of > any free program. We wish to make sure that a company cannot > effectively restrict the users of a free program by obtaining a > restrictive license from a patent holder. Therefore, we insist that > any patent license obtained for a version of the library must be > consistent with the full freedom of use specified in this license. > > Most GNU software, including some libraries, is covered by the > ordinary GNU General Public License. This license, the GNU Lesser > General Public License, applies to certain designated libraries, and > is quite different from the ordinary General Public License. We use > this license for certain libraries in order to permit linking those > libraries into non-free programs. > > When a program is linked with a library, whether statically or using > a shared library, the combination of the two is legally speaking a > combined work, a derivative of the original library. The ordinary > General Public License therefore permits such linking only if the > entire combination fits its criteria of freedom. The Lesser General > Public License permits more lax criteria for linking other code with > the library. > > We call this license the "Lesser" General Public License because it > does Less to protect the user's freedom than the ordinary General > Public License. It also provides other free software developers Less > of an advantage over competing non-free programs. These disadvantages > are the reason we use the ordinary General Public License for many > libraries. However, the Lesser license provides advantages in certain > special circumstances. > > For example, on rare occasions, there may be a special need to > encourage the widest possible use of a certain library, so that it becomes > a de-facto standard. To achieve this, non-free programs must be > allowed to use the library. A more frequent case is that a free > library does the same job as widely used non-free libraries. In this > case, there is little to gain by limiting the free library to free > software only, so we use the Lesser General Public License. > > In other cases, permission to use a particular library in non-free > programs enables a greater number of people to use a large body of > free software. For example, permission to use the GNU C Library in > non-free programs enables many more people to use the whole GNU > operating system, as well as its variant, the GNU/Linux operating > system. > > Although the Lesser General Public License is Less protective of the > users' freedom, it does ensure that the user of a program that is > linked with the Library has the freedom and the wherewithal to run > that program using a modified version of the Library. > > The precise terms and conditions for copying, distribution and > modification follow. Pay close attention to the difference between a > "work based on the library" and a "work that uses the library". The > former contains code derived from the library, whereas the latter must > be combined with the library in order to run. > > GNU LESSER GENERAL PUBLIC LICENSE > TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION > > 0. This License Agreement applies to any software library or other > program which contains a notice placed by the copyright holder or > other authorized party saying it may be distributed under the terms of > this Lesser General Public License (also called "this License"). > Each licensee is addressed as "you". > > A "library" means a collection of software functions and/or data > prepared so as to be conveniently linked with application programs > (which use some of those functions and data) to form executables. > > The "Library", below, refers to any such software library or work > which has been distributed under these terms. A "work based on the > Library" means either the Library or any derivative work under > copyright law: that is to say, a work containing the Library or a > portion of it, either verbatim or with modifications and/or translated > straightforwardly into another language. (Hereinafter, translation is > included without limitation in the term "modification".) > > "Source code" for a work means the preferred form of the work for > making modifications to it. For a library, complete source code means > all the source code for all modules it contains, plus any associated > interface definition files, plus the scripts used to control compilation > and installation of the library. > > Activities other than copying, distribution and modification are not > covered by this License; they are outside its scope. The act of > running a program using the Library is not restricted, and output from > such a program is covered only if its contents constitute a work based > on the Library (independent of the use of the Library in a tool for > writing it). Whether that is true depends on what the Library does > and what the program that uses the Library does. > > 1. You may copy and distribute verbatim copies of the Library's > complete source code as you receive it, in any medium, provided that > you conspicuously and appropriately publish on each copy an > appropriate copyright notice and disclaimer of warranty; keep intact > all the notices that refer to this License and to the absence of any > warranty; and distribute a copy of this License along with the > Library. > > You may charge a fee for the physical act of transferring a copy, > and you may at your option offer warranty protection in exchange for a > fee. > > 2. You may modify your copy or copies of the Library or any portion > of it, thus forming a work based on the Library, and copy and > distribute such modifications or work under the terms of Section 1 > above, provided that you also meet all of these conditions: > > a) The modified work must itself be a software library. > > b) You must cause the files modified to carry prominent notices > stating that you changed the files and the date of any change. > > c) You must cause the whole of the work to be licensed at no > charge to all third parties under the terms of this License. > > d) If a facility in the modified Library refers to a function or a > table of data to be supplied by an application program that uses > the facility, other than as an argument passed when the facility > is invoked, then you must make a good faith effort to ensure that, > in the event an application does not supply such function or > table, the facility still operates, and performs whatever part of > its purpose remains meaningful. > > (For example, a function in a library to compute square roots has > a purpose that is entirely well-defined independent of the > application. Therefore, Subsection 2d requires that any > application-supplied function or table used by this function must > be optional: if the application does not supply it, the square > root function must still compute square roots.) > > These requirements apply to the modified work as a whole. If > identifiable sections of that work are not derived from the Library, > and can be reasonably considered independent and separate works in > themselves, then this License, and its terms, do not apply to those > sections when you distribute them as separate works. But when you > distribute the same sections as part of a whole which is a work based > on the Library, the distribution of the whole must be on the terms of > this License, whose permissions for other licensees extend to the > entire whole, and thus to each and every part regardless of who wrote > it. > > Thus, it is not the intent of this section to claim rights or contest > your rights to work written entirely by you; rather, the intent is to > exercise the right to control the distribution of derivative or > collective works based on the Library. > > In addition, mere aggregation of another work not based on the Library > with the Library (or with a work based on the Library) on a volume of > a storage or distribution medium does not bring the other work under > the scope of this License. > > 3. You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. To do > this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version 2, > instead of to this License. (If a newer version than version 2 of the > ordinary GNU General Public License has appeared, then you can specify > that version instead if you wish.) Do not make any other change in > these notices. > > Once this change is made in a given copy, it is irreversible for > that copy, so the ordinary GNU General Public License applies to all > subsequent copies and derivative works made from that copy. > > This option is useful when you wish to copy part of the code of > the Library into a program that is not a library. > > 4. You may copy and distribute the Library (or a portion or > derivative of it, under Section 2) in object code or executable form > under the terms of Sections 1 and 2 above provided that you accompany > it with the complete corresponding machine-readable source code, which > must be distributed under the terms of Sections 1 and 2 above on a > medium customarily used for software interchange. > > If distribution of object code is made by offering access to copy > from a designated place, then offering equivalent access to copy the > source code from the same place satisfies the requirement to > distribute the source code, even though third parties are not > compelled to copy the source along with the object code. > > 5. A program that contains no derivative of any portion of the > Library, but is designed to work with the Library by being compiled or > linked with it, is called a "work that uses the Library". Such a > work, in isolation, is not a derivative work of the Library, and > therefore falls outside the scope of this License. > > However, linking a "work that uses the Library" with the Library > creates an executable that is a derivative of the Library (because it > contains portions of the Library), rather than a "work that uses the > library". The executable is therefore covered by this License. > Section 6 states terms for distribution of such executables. > > When a "work that uses the Library" uses material from a header file > that is part of the Library, the object code for the work may be a > derivative work of the Library even though the source code is not. > Whether this is true is especially significant if the work can be > linked without the Library, or if the work is itself a library. The > threshold for this to be true is not precisely defined by law. > > If such an object file uses only numerical parameters, data > structure layouts and accessors, and small macros and small inline > functions (ten lines or less in length), then the use of the object > file is unrestricted, regardless of whether it is legally a derivative > work. (Executables containing this object code plus portions of the > Library will still fall under Section 6.) > > Otherwise, if the work is a derivative of the Library, you may > distribute the object code for the work under the terms of Section 6. > Any executables containing that work also fall under Section 6, > whether or not they are linked directly with the Library itself. > > 6. As an exception to the Sections above, you may also combine or > link a "work that uses the Library" with the Library to produce a > work containing portions of the Library, and distribute that work > under terms of your choice, provided that the terms permit > modification of the work for the customer's own use and reverse > engineering for debugging such modifications. > > You must give prominent notice with each copy of the work that the > Library is used in it and that the Library and its use are covered by > this License. You must supply a copy of this License. If the work > during execution displays copyright notices, you must include the > copyright notice for the Library among them, as well as a reference > directing the user to the copy of this License. Also, you must do one > of these things: > > a) Accompany the work with the complete corresponding > machine-readable source code for the Library including whatever > changes were used in the work (which must be distributed under > Sections 1 and 2 above); and, if the work is an executable linked > with the Library, with the complete machine-readable "work that > uses the Library", as object code and/or source code, so that the > user can modify the Library and then relink to produce a modified > executable containing the modified Library. (It is understood > that the user who changes the contents of definitions files in the > Library will not necessarily be able to recompile the application > to use the modified definitions.) > > b) Use a suitable shared library mechanism for linking with the > Library. A suitable mechanism is one that (1) uses at run time a > copy of the library already present on the user's computer system, > rather than copying library functions into the executable, and (2) > will operate properly with a modified version of the library, if > the user installs one, as long as the modified version is > interface-compatible with the version that the work was made with. > > c) Accompany the work with a written offer, valid for at > least three years, to give the same user the materials > specified in Subsection 6a, above, for a charge no more > than the cost of performing this distribution. > > d) If distribution of the work is made by offering access to copy > from a designated place, offer equivalent access to copy the above > specified materials from the same place. > > e) Verify that the user has already received a copy of these > materials or that you have already sent this user a copy. > > For an executable, the required form of the "work that uses the > Library" must include any data and utility programs needed for > reproducing the executable from it. However, as a special exception, > the materials to be distributed need not include anything that is > normally distributed (in either source or binary form) with the major > components (compiler, kernel, and so on) of the operating system on > which the executable runs, unless that component itself accompanies > the executable. > > It may happen that this requirement contradicts the license > restrictions of other proprietary libraries that do not normally > accompany the operating system. Such a contradiction means you cannot > use both them and the Library together in an executable that you > distribute. > > 7. You may place library facilities that are a work based on the > Library side-by-side in a single library together with other library > facilities not covered by this License, and distribute such a combined > library, provided that the separate distribution of the work based on > the Library and of the other library facilities is otherwise > permitted, and provided that you do these two things: > > a) Accompany the combined library with a copy of the same work > based on the Library, uncombined with any other library > facilities. This must be distributed under the terms of the > Sections above. > > b) Give prominent notice with the combined library of the fact > that part of it is a work based on the Library, and explaining > where to find the accompanying uncombined form of the same work. > > 8. You may not copy, modify, sublicense, link with, or distribute > the Library except as expressly provided under this License. Any > attempt otherwise to copy, modify, sublicense, link with, or > distribute the Library is void, and will automatically terminate your > rights under this License. However, parties who have received copies, > or rights, from you under this License will not have their licenses > terminated so long as such parties remain in full compliance. > > 9. You are not required to accept this License, since you have not > signed it. However, nothing else grants you permission to modify or > distribute the Library or its derivative works. These actions are > prohibited by law if you do not accept this License. Therefore, by > modifying or distributing the Library (or any work based on the > Library), you indicate your acceptance of this License to do so, and > all its terms and conditions for copying, distributing or modifying > the Library or works based on it. > > 10. Each time you redistribute the Library (or any work based on the > Library), the recipient automatically receives a license from the > original licensor to copy, distribute, link with or modify the Library > subject to these terms and conditions. You may not impose any further > restrictions on the recipients' exercise of the rights granted herein. > You are not responsible for enforcing compliance by third parties with > this License. > > 11. If, as a consequence of a court judgment or allegation of patent > infringement or for any other reason (not limited to patent issues), > conditions are imposed on you (whether by court order, agreement or > otherwise) that contradict the conditions of this License, they do not > excuse you from the conditions of this License. If you cannot > distribute so as to satisfy simultaneously your obligations under this > License and any other pertinent obligations, then as a consequence you > may not distribute the Library at all. For example, if a patent > license would not permit royalty-free redistribution of the Library by > all those who receive copies directly or indirectly through you, then > the only way you could satisfy both it and this License would be to > refrain entirely from distribution of the Library. > > If any portion of this section is held invalid or unenforceable under any > particular circumstance, the balance of the section is intended to apply, > and the section as a whole is intended to apply in other circumstances. > > It is not the purpose of this section to induce you to infringe any > patents or other property right claims or to contest validity of any > such claims; this section has the sole purpose of protecting the > integrity of the free software distribution system which is > implemented by public license practices. Many people have made > generous contributions to the wide range of software distributed > through that system in reliance on consistent application of that > system; it is up to the author/donor to decide if he or she is willing > to distribute software through any other system and a licensee cannot > impose that choice. > > This section is intended to make thoroughly clear what is believed to > be a consequence of the rest of this License. > > 12. If the distribution and/or use of the Library is restricted in > certain countries either by patents or by copyrighted interfaces, the > original copyright holder who places the Library under this License may add > an explicit geographical distribution limitation excluding those countries, > so that distribution is permitted only in or among countries not thus > excluded. In such case, this License incorporates the limitation as if > written in the body of this License. > > 13. The Free Software Foundation may publish revised and/or new > versions of the Lesser General Public License from time to time. > Such new versions will be similar in spirit to the present version, > but may differ in detail to address new problems or concerns. > > Each version is given a distinguishing version number. If the Library > specifies a version number of this License which applies to it and > "any later version", you have the option of following the terms and > conditions either of that version or of any later version published by > the Free Software Foundation. If the Library does not specify a > license version number, you may choose any version ever published by > the Free Software Foundation. > > 14. If you wish to incorporate parts of the Library into other free > programs whose distribution conditions are incompatible with these, > write to the author to ask for permission. For software which is > copyrighted by the Free Software Foundation, write to the Free > Software Foundation; we sometimes make exceptions for this. Our > decision will be guided by the two goals of preserving the free status > of all derivatives of our free software and of promoting the sharing > and reuse of software generally. > > NO WARRANTY > > 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO > WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. > EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR > OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY > KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE > IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE > LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME > THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. > > 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN > WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY > AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU > FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR > CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE > LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING > RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A > FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF > SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH > DAMAGES. > > END OF TERMS AND CONDITIONS > > How to Apply These Terms to Your New Libraries > > If you develop a new library, and you want it to be of the greatest > possible use to the public, we recommend making it free software that > everyone can redistribute and change. You can do so by permitting > redistribution under these terms (or, alternatively, under the terms of the > ordinary General Public License). > > To apply these terms, attach the following notices to the library. It is > safest to attach them to the start of each source file to most effectively > convey the exclusion of warranty; and each file should have at least the > "copyright" line and a pointer to where the full notice is found. > > > Copyright (C) > > This library is free software; you can redistribute it and/or > modify it under the terms of the GNU Lesser General Public > License as published by the Free Software Foundation; either > version 2.1 of the License, or (at your option) any later version. > > This library is distributed in the hope that it will be useful, > but WITHOUT ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > Lesser General Public License for more details. > > You should have received a copy of the GNU Lesser General Public > License along with this library; if not, write to the Free Software > Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > > Also add information on how to contact you by electronic and paper mail. > > You should also get your employer (if you work as a programmer) or your > school, if any, to sign a "copyright disclaimer" for the library, if > necessary. Here is a sample; alter the names: > > Yoyodyne, Inc., hereby disclaims all copyright interest in the > library `Frob' (a library for tweaking knobs) written by James Random Hacker. > > , 1 April 1990 > Ty Coon, President of Vice > > That's all there is to it! > ------------------------ end of proposed license ------------------ > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From gjhanna at gmail.com Sun Mar 11 14:21:17 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Mon, 12 Mar 2007 09:21:17 +1300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hi Pavel, We are using RXTX under VMWare server in production, quite satisfactorily. We're using Red Hat Enterprise Server 4, and ... Whatever the "enterprise" VMWare product is. Regards, Greg H > Subject: [Rxtx] RXTX under VMWare server > To: rxtx at qbang.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. [ ... snip ... ] -- Pavel Parkhomenko -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070311/4cebb6f9/attachment-0009.html From gergg at cox.net Sun Mar 11 23:39:19 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 12 Mar 2007 00:39:19 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: <45F4E787.6050502@cox.net> Trent Jarvi wrote: > I can start going through the method interfaces later this week and giving > feedback. I would suggest that the JSR should not be too generic in > nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel > drivers that intend to look like EIA232 ports at the kernel driver level. > > some ideas: > > EIA232PortInterface > TermiosInterface > SerialPortInterface > > Something that differentiates this from thing like USB, I2C, ... which > should not have to deal with legacy serial claiming to be the comm api. I'm going to throw out a suggestion, which I am mostly serious about. What would happen if we took the appropriate bits of the J2ME connector API, and just used that as the new COMM API so that finally JSE and JME had a common foundation for these kinds of things? Gregg Wonderly From ra85551 at gmail.com Mon Mar 12 09:08:37 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Mon, 12 Mar 2007 18:08:37 +0300 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Should any application use the modem, HyperTerminal won't be able to talk to the modem. But it actually can send and receive AT comands, while my application cannot :-( > Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Thansk for the reference. I examined that example and found that there's no significant differences between my read/write implementation and that one, except that SimpleSnuV1 listens for serialEvent's, but not for sake of data retrieval, just for printing them out - I don't know why ;-) > Note that modems could care less what OS is on top. If you are trying to > match new lines to the OS and sending it to the mode for AT commands, > thats probably a mistake. I do send strings to serial port, not to OS, and do try to get answers back. If it is the mistake, what's the right way? > Also it would not hurt to print out the > individual bytes that you are sending to make sure they did not get > mangled along the path. Yeah, I am printing these bytes before doing write, but it means that I only see what I intend to write. How can I ensure that these bytes have gone out of the box and reached my modem? BTW, I found that my send/receive method is complex enough, so I've rewritten it. Please, see the following code and point any mistakes, because I don't know where can they remain yet. private static final int LARGE_TIMEOUT = 15000; private static final int SMALL_TIMEOUT = 500; ... private String sendATCommand(String command, String waitFor, boolean isRegex, boolean isAddCRLF) throws BeaconConnectException { byte[] buffer = new byte[512]; int offset; String result = ""; try { if (waitFor != null) { serialPort.enableReceiveTimeout(LARGE_TIMEOUT); } else { serialPort.enableReceiveTimeout(SMALL_TIMEOUT); } if (command != null) { OutputStream serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } offset = 0; InputStream serialInput = serialPort.getInputStream(); while (serialInput.available() != -1) { int bytesRead = serialInput.read(buffer, offset, buffer.length - offset); if (bytesRead == 0) { break; } offset += bytesRead; result = new String(buffer, 0, offset).trim(); if (waitFor != null) { System.out.println(result); if (isRegex && result.matches(waitFor) || result.contains(waitFor)) { break; } } } } catch (UnsupportedCommOperationException e) { throw new MyException("unsupported operation"); } catch (IOException e) { throw new MytException("serial I/O error"); } return result; } -- Pavel Parkhomenko From clayno at hotpop.com Thu Mar 15 02:47:34 2007 From: clayno at hotpop.com (Christopher Layno) Date: Thu, 15 Mar 2007 16:47:34 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi, we're using the latest release of rxtx (2.1-7r2) for our system that has two applications using the library. one application sends requests to the modem while the other simply checks the modem status. we deployed our system on a pentium machine with red hat linux 9.0 installed. now the problem arises when these two applications try to access the same modem at the same time. one of them will eventually have to throw the PortInUseException as shown below: 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException gnu.io.PortInUseException: root PID = 743 Program = java root PID = 743 Program = java root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) this was expected. what we didn't expect though was that if we repeat the scenario 5 times, always 5 times, the application would also throw a VM error: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4473CD21 Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so Current Java thread: at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) - locked <0x44cfd4c8> (a gnu.io.CommPortIdentifier) at ************ at ************ - locked <0x4476a468> (a **********) at ************ at ************ at ************ at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java :261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages( TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run( TCPTransport.java:701) at java.lang.Thread.run(Thread.java:534) note: i replaced some sensitive data with asterisks our team has looked everywhere on the internet, including your mail archives, for a solution to this problem but to no avail. i really hope you could help us out on this one. thanks in advance! best regards, chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070315/1936460a/attachment-0009.html From tjarvi at qbang.org Fri Mar 16 04:30:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 04:30:25 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: On Thu, 15 Mar 2007, Christopher Layno wrote: > hi, > > we're using the latest release of rxtx (2.1-7r2) for our system that has two > applications using the library. one application sends requests to the modem > while the other simply checks the modem status. we deployed our system on a > pentium machine with red hat linux 9.0 installed. > > now the problem arises when these two applications try to access the same > modem at the same time. one of them will eventually have to throw the > PortInUseException as shown below: > > 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException > gnu.io.PortInUseException: root PID = 743 Program = java root PID = > 743 Program = java root PID = 743 Program = ??? root PID = 743 Program > = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root > PID = 743 Program = ??? root PID = 743 Program = ??? > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > > this was expected. what we didn't expect though was that if we repeat the > scenario 5 times, always 5 times, the application would also throw a VM > error: > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x4473CD21 > Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 > Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so > > Current Java thread: > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) Hi Chris The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. The code is originally by Werner Almesberger. He gave us permission to use it in rxtx. You might look at what has changed since 1998 in his fuser application. Or you can just do like other OSs and do the following in fuserImp.c JNIEXPORT jstring JNICALL Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv *env, jobject obj, jstring arg) { return (*env)->NewStringUTF(env, "Unknown Application"); } It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. -- Trent Jarvi tjarvi at qang.org From Adrien.TOS at ingenico.com Fri Mar 16 05:11:12 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Fri, 16 Mar 2007 12:11:12 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903CBC312@frsnprexc1.usr.ingenico.loc> Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070316/972ab214/attachment-0009.html From joachim at buechse.de Fri Mar 16 05:13:24 2007 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 16 Mar 2007 12:13:24 +0100 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. From tjarvi at qbang.org Fri Mar 16 16:36:29 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 16:36:29 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Fri Mar 16 16:02:23 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 16 Mar 2007 18:02:23 -0400 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Not all platforms are Unix based. Also mixing native library usage and command-line calls is not an elegant solution, IMHO. One or the other, but not both. Andre On 16-Mar-07, at 07:13 , Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is > trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We >> only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From clayno at hotpop.com Sun Mar 18 22:17:28 2007 From: clayno at hotpop.com (Christopher Layno) Date: Mon, 19 Mar 2007 12:17:28 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi everyone, thank you so much for your replies. they were really helpful. anyway, before i sent the email, my team was already implementing a temporary solution by using joachim's suggestion. we invoked a lsof command from our java code although i share the same concern with trent and andre-john about portability issues. that's why i said it's just temporary. my superiors have yet to approve our bug fix. so my question now is this: is recompiling the rxtx source code the only way to solve this problem? because if it's the only solution, then i think my superiors would rather have a new release from the rxtx community itself that fixes this bug(?) rather than have my team recompile the source code. best regards, chris Trent Jarvi wrote: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. ... It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070318/237463b2/attachment-0009.html From tjarvi at qbang.org Mon Mar 19 16:20:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Mar 2007 16:20:52 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: Hi Chris I can compile a new version after the 21st if you do not feel comfortable doing so. Please send me an email reminder off-line then. On Mon, 19 Mar 2007, Christopher Layno wrote: > hi everyone, > > thank you so much for your replies. they were really helpful. > > anyway, before i sent the email, my team was already implementing a > temporary solution by using joachim's suggestion. > we invoked a lsof command from our java code although i share the same > concern with trent and andre-john about > portability issues. that's why i said it's just temporary. my superiors have > yet to approve our bug fix. > > so my question now is this: is recompiling the rxtx source code the only way > to solve this problem? because if it's the only > solution, then i think my superiors would rather have a new release from the > rxtx community itself that fixes this bug(?) > rather than have my team recompile the source code. > > best regards, > > chris > > Trent Jarvi wrote: > > Hi Joachim > > It would be nice to have that functionality but calling the program > introduces too many issues imho. Explaining to someone why rxtx invoked a > rogue lsof does not sound very interesting. > > On Fri, 16 Mar 2007, Joachim Buechse wrote: > > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: > > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. > > _______________________________________________ > Rxtx mailing list > Rxtx 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 Eric.Arseneau at sun.com Tue Mar 20 11:47:33 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Tue, 20 Mar 2007 10:47:33 -0700 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 Message-ID: <46001E35.9040608@sun.com> Anyone have any experience with RXTX working with JDK 6 on other platforms ? From mm at UDel.Edu Tue Mar 20 12:18:29 2007 From: mm at UDel.Edu (Mike Markowski) Date: Tue, 20 Mar 2007 14:18:29 -0400 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 In-Reply-To: <46001E35.9040608@sun.com> References: <46001E35.9040608@sun.com> Message-ID: <46002575.4000306@udel.edu> Eric Arseneau wrote: > Anyone have any experience with RXTX working with JDK 6 on other platforms ? I'm using 32 bit intel, gentoo linux, jdk6 with no problems. My applications only use a serial port, though, nothing on the parallel port. Mike From falko.guderian at gmx.de Wed Mar 21 08:17:35 2007 From: falko.guderian at gmx.de (Falko Guderian) Date: Wed, 21 Mar 2007 15:17:35 +0100 Subject: [Rxtx] RXTX binaries for SH4 Message-ID: <46013E7F.40102@gmx.de> Dear developers, I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no possiblities to compile the source code. Better, I'm not able to do this at the moment. Can you provide me with rxtxSerial.dll (SH4) in the rxtx-2.1-8-testing version? (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) The reason for the testing version is I need custom baud rates. Thanks for help. Kind regards, Falko Guderian From tjarvi at qbang.org Wed Mar 21 21:38:37 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Mar 2007 21:38:37 -0600 (MDT) Subject: [Rxtx] RXTX binaries for SH4 In-Reply-To: <46013E7F.40102@gmx.de> References: <46013E7F.40102@gmx.de> Message-ID: On Wed, 21 Mar 2007, Falko Guderian wrote: > Dear developers, > > I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no > possiblities to compile the source code. Better, I'm not able to do this > at the moment. Can you provide me with rxtxSerial.dll (SH4) in the > rxtx-2.1-8-testing version? > (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) > > The reason for the testing version is I need custom baud rates. > > Thanks for help. > Hi Falko WinCE binary format is not supported by gcc. That makes compiling limited to those familiar with the WinCE tools. I hope someone is able to provide them for you but it is not likely. WinCE has been compiled by others in the past but rxtx.org builds have never included WinCE. There is some information with the source concerning WinCE builds if you decide to do it. We can share your results too if you like. The source in the WinCE has never been updated for the custom baud rate. That would need changes from the main source I presume. If you look at the source, you will note that Michal Hobot created a mini fork in the source to handle wince but it has not been updated for 3 years. -- Trent Jarvi tjarvi at qbang.org From Adrien.TOS at ingenico.com Thu Mar 22 07:08:55 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Thu, 22 Mar 2007 14:08:55 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Hi everybody, Do you have any comments on this issue? Thanks! AT ________________________________ De : Adrien TOS Envoy? : vendredi 16 mars 2007 12:11 ? : 'rxtx at qbang.org' Cc : Adrien TOS Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070322/2306c538/attachment-0009.html From jeremy.reeve at zen.co.uk Mon Mar 19 07:36:04 2007 From: jeremy.reeve at zen.co.uk (Jeremy S. Reeve) Date: Mon, 19 Mar 2007 13:36:04 +0000 Subject: [Rxtx] rxtx failing to compile on Fedora Core 6 Message-ID: <1174311364.21865.6.camel@d9thc> When trying to compile latest source : rxtx-2.1-7r2 I get the following when running configure: ---------------- checking os.version 2.6.18-1.2200.fc5smp WARNING: configure is having a hard time determining which directory contains the file jni_md.h. Edit Makefile and fix the variable JAVANATINC to point to the correct directory. The following options are available: /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/ /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/linux/ If there are more than one option available the first was selected. WARNING: Kernel include files do not match the current kernel configure: creating ./config.status ------------------------ which seems OK checking the resultant Makefile but when attempting to build with gmake install I get the following output : ---------------------- 34 problems (34 warnings)/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/javah -classpath .:/home/jsr/rxtxsrc/rxtx-2.1-7r2:/home/jsr/rxtxsrc/rxtx-2.1-7r2/src:/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/ext/RXTXcomm.jar -d i686-pc-linux-gnu -jni `(for i in CommDriver CommPortEnumerator CommPortIdentifier CommPort CommPortOwnershipListener Configure I2C I2CPortEvent I2CPortEventListener I2CPort LPRPort NoSuchPortException ParallelPortEvent ParallelPortEventListener ParallelPort PortInUseException Raw RawPortEvent RawPortEventListener RawPort RS485 RS485PortEvent RS485PortEventListener RS485Port RXTXCommDriver RXTXPort RXTXVersion SerialPortEvent SerialPortEventListener SerialPort UnsupportedCommOperationException UnSupportedLoggerException Zystem;do \ if grep > /dev/null native.* \( /home/jsr/rxtxsrc/rxtx-2.1-7r2/./src/$i.java; then \ echo gnu.io.$i; \ fi; \ done)` i686-pc-linux-gnu/gnu_io_CommPortIdentifier.h: No such file or directory make: *** [/home/jsr/rxtxsrc/rxtx-2.1-7r2/gnu/io/CommDriver.class] Error 1 ------------------------ Any ideas or pointers? Regards, Jeremy From tjarvi at qbang.org Sat Mar 24 08:12:54 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 Mar 2007 08:12:54 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > From Adrien.TOS at ingenico.com Sat Mar 24 11:53:22 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Sat, 24 Mar 2007 18:53:22 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> I do not have the threshold setting enabled, I have explicitely disabled it with: port_.disableReceiveThreshold(); I have also run the same tests with the threshold setting enabled, but they also fail in the same way as described below. So it seems there is a problem with timeout handling on Win32? ________________________________ From: rxtx-bounces at qbang.org on behalf of Trent Jarvi Sent: Sat 3/24/2007 3:12 PM To: RXTX Developers and Users Subject: Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 8312 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20070324/f9e39c9b/attachment-0009.bin From greg.johnson at manchester.ac.uk Sun Mar 25 13:41:36 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Sun, 25 Mar 2007 21:41:36 +0200 Subject: [Rxtx] Mac intel weirdness Message-ID: Hi folks, I'm trying to get rxtx to work on my macbook pro with a USB-serial dongle on it. I am using the 2.1-8 code from the CVS (though it seems to report itself as 2.1-7: makes it difficult to prove to oneself that the changes have 'taken'! - line 4210 in SerialImp.c, line 40 in RXTXVersion.java) I am trying the 2.1-8 because of horrible lock problems in 2.1-7. However, the serialport closure code seems to be broken - it won't close because it believes the (previously opened!) port doesn't exist. Here is what I'm trying: 0. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "false" 1. Open a port Serialport serialport = (SerialPort) commportidentifier.open ("test",100); 2. Talk to a device ... 3. Close port serialport.close(); 4. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "true" - why is this? 5. Try to reopen port Serialport serialport2 = (SerialPort) commportidentifier.open("test", 100); throws PortInUseException. I've dug around a bit in the source, and it seems the SerialPort.close () should call the CommPortIdentifier.internalClosePort() (line 67 of CommPort.java). However, I crash out with the NoSuchPortException when getPortIdentifier is called. Which seems quite weird to me, seeing as it is called on this - which was create just beforehand. Does anyone know how to fix this? Cheers, greg From knute at frazmtn.com Sat Mar 24 10:32:38 2007 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 24 Mar 2007 09:32:38 -0700 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc>, Message-ID: <4604F036.17833.135298@knute.frazmtn.com> > >The behavior of timeout depends upon the setting of the threshold. Do you >have the threshold setting? > This is the same bug I reported last fall. There was a fellow that sent me an email asking if it had been fixed. I told him I didn't think so. He got somebody to write a fix for him but I have not been able to contact him again for the actual changes. The inaccurate timeout and the failure of blocking when no timeouts are set is a serious bug in my humble opinion and renders the software unusable for my applications. I'd really like to have an alternative to the Sun comm api but there just isn't one that I know of. -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Mar 26 16:17:00 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 26 Mar 2007 16:17:00 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> Message-ID: >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. From ra85551 at gmail.com Tue Mar 27 10:18:36 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Tue, 27 Mar 2007 20:18:36 +0400 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Ultimately I found a solution. At first, that wasn't actually the VMWare + WinXP + RXTX issue, that was WinXP + RXTX issue. But on pure XP it sometimes workes, sometimes not, while under VMWare I had never seen my snippet working at all. SimpleSnuV1.java would not help me, because there is only one line I missed, and SimpleSnuV1.java also doesn't contain it! It is as follows: serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_OUT | SerialPort.FLOWCONTROL_RTSCTS_IN); Thank you for your attention. -- Pavel Parkhomenko From griff at op.pl Wed Mar 28 01:28:19 2007 From: griff at op.pl (griff@op.pl) Date: Wed, 28 Mar 2007 09:28:19 +0200 Subject: [Rxtx] No blocking read on Windows. Message-ID: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/5d07d571/attachment-0009.html -------------- next part -------------- Hi, I have problem that InputStram.read() (SerialPort)?returns -1 instead blocking and waiting for data. I found that this problem was ?known in 2005 : ? >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > >> Hi Trent >> >> Thanks for the fast response. >> Here's a Q&D test program for the blocking read on windows that just >> attempts to read one byte, and prints the resulting byte. On my system it >> returns -1, where I expect that it keeps waiting for data. >> >This isn't happening on Linux so the bug is in src/termios.c.? I'll have >something this weekend to fix that. I'm using RXTX 2.1.7r2 and the problem still is here. Im using Windows XP and java 1.5 disableReciveTimeout() and disableReciveTreshhold() dont help. ? best regards ? Piotr Zielniok From Adrien.TOS at ingenico.com Wed Mar 28 01:40:46 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Wed, 28 Mar 2007 09:40:46 +0200 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903E88880@frsnprexc1.usr.ingenico.loc> Looking at the code, it seems there is no support for infinite timeout? And maybe the count++ < 20 condition is breaking out of the loop too early? The only condition to break out of the loop should either be the timeout has expired or the number of requested bytes has been received. -----Message d'origine----- De : rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] De la part de Trent Jarvi Envoy? : mardi 27 mars 2007 00:17 ? : RXTX Developers and Users Objet : Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From j.kenneth.gentle at acm.org Wed Mar 28 06:44:15 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 28 Mar 2007 08:44:15 -0400 Subject: [Rxtx] No blocking read on Windows. In-Reply-To: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> References: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> Message-ID: <200703281844.l2SIiITW028614@qbang.org> Just another "ME TOO!" - I'm seeing this problem on Windows XP, jre for windows XP/Embedded. I cranked receiveTimeout up to Integer.MAX_INT, but it doesn't seem to wait that long At 03:28 2007-03-28, you wrote: >Hi, >I have problem that InputStram.read() (SerialPort) returns -1 >instead blocking and waiting for data. I found that this problem >was known in 2005 : > > >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > > > >> Hi Trent > >> > >> Thanks for the fast response. > >> Here's a Q&D test program for the blocking read on windows that just > >> attempts to read one byte, and prints the resulting byte. On my system it > >> returns -1, where I expect that it keeps waiting for data. > >> > > >This isn't happening on Linux so the bug is in src/termios.c. I'll have > >something this weekend to fix that. > >I'm using RXTX 2.1.7r2 and the problem still is here. >Im using Windows XP and java 1.5 >disableReciveTimeout() and disableReciveTreshhold() dont help. > >best regards > >Piotr Zielniok > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From greg.johnson at manchester.ac.uk Wed Mar 28 14:43:29 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Wed, 28 Mar 2007 22:43:29 +0200 Subject: [Rxtx] Cannot close and reopen serial port Message-ID: <377F9765-7A9D-4CE9-9176-FFB63A2594F0@manchester.ac.uk> Dear all, It appears I cannot close a port properly: SerialPort serialport = portid.open("myprog",100); // do some stuff, all works fine serialport.close(); // all seems fine but... SerialPort sp2 = portid.open("myprog",100); throws PortInUseException. And when I dig into the rxtx code, I find in CommPort.java, in close(): CommPortIdentifier cp = CommPortIdentifier.getPortIdentifier(this); (line 64 or there abouts) but this throws a NoSuchPortException which is caught but ignored (line 74ish). Can anyone suggest how this could happen: a port that was valid, opened, and used, throws a NSPE when it comes to closing it? I'm pulling my (remaining) hair out over this one! Cheers, greg PS And thanks for RXTX - it's great to have! PPS (21.-7. winxp/osx both, java 1.5) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/c28852fc/attachment-0009.html From rxtx at vrijheidslaan.net Fri Mar 30 16:52:50 2007 From: rxtx at vrijheidslaan.net (Rob) Date: Fri, 30 Mar 2007 22:52:50 -0000 Subject: [Rxtx] Cvs Question Message-ID: <61896.80.126.150.87.1175295162.squirrel@webmail.provalue.nl> Hi There, Im trying to get the latest version to work on mac osx. Problem is that i can't checkout version 2.1.8. Probably my fault but can some one please give me the alternative commands for: [user at myhost]$ export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot [user at myhost]$ cvs login Thanx, Rob From ra85551 at gmail.com Thu Mar 1 03:47:06 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Thu, 1 Mar 2007 13:47:06 +0300 Subject: [Rxtx] enableReceiveTimeout() issue Message-ID: Hello, world! I found a limitation of 16300 ms for CommPort's enableReceiveTimeout() method, while in original javax.comm docs there are no any references to that. Is that a bug or feature? I actually need longer timeouts sometimees. -- Pavel Parkhomenko From lyon at docjava.com Thu Mar 1 07:54:17 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 01 Mar 2007 09:54:17 -0500 Subject: [Rxtx] parametric singleton design pattern In-Reply-To: References: <22d55aea0702081207q5e7f6785l352d498d6f5f9fb1@mail.gmail.com> <22d55aea0702100034o3bcf42f3j1d1a6257029a67b0@mail.gmail.com> Message-ID: Hi All, I have been thinking about the use of a design pattern to cache resources that are consumed by processes. Toward that end, I have arrived at a parametric singleton design pattern, which I mentioned on this list some time ago. The idea has been published at: http://www.jot.fm/issues/issue_2007_03/column2 I can't help but think that there should be an API available for dealing with the tracking of serial port usage. Perhaps it is a kind of resource manager called the: SerialPortManager basic prototypes already exist in this vain. See, for example: http://www.ce.rit.edu/research/projects/2005_fall/rt_poolsystem/doc/PoolMon/SerialPortManager.html http://www.eventhelix.com/RealtimeMantra/PatternCatalog/serial_port_design_pattern.htm And others shown by a google search on "SerialPortManager" Cheers! - Doug From Eric.Arseneau at sun.com Thu Mar 1 10:15:03 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:15:03 -0800 Subject: [Rxtx] Any known Java 6 issues with RXTX 2.1-7r2 ? Message-ID: <45E70A17.1060206@sun.com> I just did a test on a recent build of Solaris 11 x86 and it seems that I can connect to my serial device fine when Java 5 is the default, but when Java 6 is the default, no go. Any information ? From Eric.Arseneau at sun.com Thu Mar 1 10:19:58 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:19:58 -0800 Subject: [Rxtx] Mac OS X and missing data Message-ID: <45E70B3E.7040908@sun.com> We have a device which is USB based but presents itself as a serial port to a machine. On my MacBook Pro I can get excellent throughput if I get my device to send data as quickly as possible. On the desktop side, if I do an type of disk IO to log the data I get, I end up with some missing data at some point. I hooked up a USB analyzer and did confirm that all the data is sent as expected to the desktop from the device. I found a work around for this, buffer the data in memory and only write the data out when I've received it all. However, when the same code and same device is attempted on a co-workers MacBook Pro (same hardware specs), I get errors and must slow down dramatically the device side's sending of data. Any ideas/recommendations on what I can do to get rid of this error ? From what I can tell, it seems that RXTX is not able to wake up to the interrupts coming in indicating data is ready, quickly enough, is there anything I can do ? From chinkaiw at hotmail.com Fri Mar 2 00:57:43 2007 From: chinkaiw at hotmail.com (Wang Chinkai) Date: Fri, 02 Mar 2007 07:57:43 +0000 Subject: [Rxtx] dynamic detect rs232 port Message-ID: Hi all I have a question about detecting rs232 port dynamicly. I have to aceess some port and detect rs232 port at the same time. Some usb device simulates rs232 port , and I can not know what the port name it gets until it connects,so I have to detect it dynamic,but I have to access another rs232 device at the same time. I found a problem. If I use CommPortIdentifier.getPortIdentifiers() to get new port list , and the other rs232 access function will not close port correctly. So , How can I solve it . Thanks. _________________________________________________________________ ?? 2GB ???? Windows Live Mail ????????????? http://ideas.live.com/programpage.aspx?versionid=5d21c51a-b161-4314-9b0e-4911fb2b2e6d From eu259473 at tele2.it Fri Mar 2 06:16:40 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 02 Mar 2007 14:16:40 +0100 Subject: [Rxtx] rxtx on HP tru 64 unix Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070302/706c7a70/attachment-0010.html From tjarvi at qbang.org Fri Mar 2 08:39:33 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 08:39:33 -0700 (MST) Subject: [Rxtx] rxtx on HP tru 64 unix In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, "Giuseppe Marchese" wrote: > Hi > > I try to install rxtx on hp tru 64 but make fails, > There are somebody that do the same and work. > > > Sorry for may english! > > Hi Giuseppe Could you provide a log of the failure? script ./configure make # use gnu make exit The information will be in the typescript created. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 2 19:56:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 19:56:52 -0700 (MST) Subject: [Rxtx] dynamic detect rs232 port In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, Wang Chinkai wrote: > Hi all > > I have a question about detecting rs232 port dynamicly. > > I have to aceess some port and detect rs232 port at the same time. > Some usb device simulates rs232 port , and I can not know > what the port name it gets until it connects,so I have to detect it > dynamic,but I have to access > another rs232 device at the same time. > > I found a problem. Hi Wang This is a known problem. The code is braindead there. In fact there needs to be events even in a rudamentary way when you add a usb dongle. I'm burried in tasks not far from rxtx but not in rxtx. I can't get to the problem but we would accept patches if you dig into it. [I'm getting to the license question earlier too; I don't have another 10%] -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Fri Mar 2 23:19:01 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 01:19:01 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Hi, Under ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable USB -> serial converter(using virtual com port drivers), with using example code pretty much straight out of http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port opens fine, enumerations all work, etc. My application calls for a large amount of data to be transferred in a short amount of time at 2,000,000 baud. My hardware sends approximately 15,232 bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL converter work fine, and the application works using C++. In C++, I do a hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); to open the port, and a boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); to read the port. The variable buffer fills with the 15238 bytes, and returns. If I do a resultz = is.read(cbuf,0,15238); in java with RXTX where is = new BufferedReader(new InputStreamReader(port.getInputStream())); and where resultz is an int, and cbuf is a char [] cbuf, resultz gets EXACTLY 3968 bytes the first time called. If I call it multiple times, I get roughly 11k total(less than what is sent), never more than the 3968 bytes per is.read() call. My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 bytes. I've played with inputbuffersize, receive threshold, receivetimeout, and so on. The FTDI virtual com port drivers that I'm using are rock solid, and have had zero problems with them using a variety of applications, some of my own, some professionally written, etc. No flow control is used anyplace, no RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. No exceptions are being thrown. What am I doing wrong, and what I can adjust to receive the full 15k bytes in one single read? Thanks! Keith From Eric.Arseneau at sun.com Fri Mar 2 23:32:07 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Fri, 02 Mar 2007 22:32:07 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <45E91667.20501@sun.com> This is the same type of thing that is happening to me on Mac OS X and does not seem to behave the same on different machines. I posted a day or two ago on this with subject "Mac OS X and missing data". Would love to hear if there is a solution to this :) From tjarvi at qbang.org Sat Mar 3 10:54:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 10:54:17 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > Hi, > > Under > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable > USB -> serial converter(using virtual com port drivers), with using example > code pretty much straight out of > http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port > opens fine, enumerations all work, etc. > > My application calls for a large amount of data to be transferred in a short > amount of time at 2,000,000 baud. My hardware sends approximately 15,232 > bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL > converter work fine, and the application works using C++. > > In C++, I do a > > hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, > OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); > > to open the port, and a > > boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); > > to read the port. > > The variable buffer fills with the 15238 bytes, and returns. > > If I do a > > resultz = is.read(cbuf,0,15238); in java with RXTX > > where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > > and where resultz is an int, and cbuf is a char [] cbuf, resultz gets > EXACTLY 3968 bytes the first time called. If I call it multiple times, I get > roughly 11k total(less than what is sent), never more than the 3968 bytes > per is.read() call. > > My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 > bytes. > > I've played with inputbuffersize, receive threshold, receivetimeout, and so > on. The FTDI virtual com port drivers that I'm using are rock solid, and > have had zero problems with them using a variety of applications, some of my > own, some professionally written, etc. No flow control is used anyplace, no > RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. > > No exceptions are being thrown. > > What am I doing wrong, and what I can adjust to receive the full 15k bytes > in one single read? > > Thanks! > Hi Keith I would expect a 20 meg application is going to have different behavior with the OS than a smaller application with respect to the kernel memory managment, schedualing, ... Something subtle could be causing problems. With respect to the recieve timeout and threshold, if you set the timeout to zero and the threshold to the size of data you expect, read should not return until it get that data. You may try with a stand alone application that tests just that with the C/C++ API. If the read is returning with less data when tested for short reads, you have found a bug in the device driver more than likely. The USB dongle vendor would probably be interested in knowing about this. As mentioned, these devices are getting very good; almost bug free. I suspect you found a bug though if you did use the threshold and timeout properly. The missing data is typical when not using flow control. When the OS buffering fills, the hardware will start dropping bytes. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:38:52 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:38:52 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> update: I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now instead of 3968. This makes sense. 128 bytes of overhead + 3968 bytes of data = 4096 transfer size 32 bytes of overhead + 992 bytes of data = 1024 transfer size. 1/4 the data = 1/4 the overhead. I rearranged my reading like so: resultz = is.read(cbuf,0,3968); resultz = is.read(cbuf,3968,3968); resultz = is.read(cbuf,7936,3968); while (!(is.ready())); // wait for ready resultz = is.read(cbuf,11904,3334); and this grabs 15,238 bytes total. BUT, I still have the quandry of the screwed up multi-bytes. I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. Approx 8% of the data. The bad bytes always seem to take the flavor of 0x2018, 0x2019, x2022, x2030, x201d. Are these maybe errors and I don't know what they enumerate to? I still can't believe some other layer isn't handling putting those bytes together all in one stream for me. Thanks Keith ----- Original Message ----- From: "Keith" To: "Bob Jacobsen" ; "RXTX Developers and Users" Sent: Saturday, March 03, 2007 11:26 AM Subject: Re: [Rxtx] is.read() only returning 3968 bytes > Bob, > > > Interesting numerical coincidence is that (max USB transfer) - (what > > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > > needed to transfer that much data. > > I was thinking along the same lines. I don't know USB well, but I do know > that those numbers were close enough to warrant investigating the > relationship between them. > > > I think what you're seeing is the internal buffering of the USB data > > stream. You'll need some form of higher-level buffering to smooth > > that out. > > Shouldn't the InputStreamReader() and BufferedReader() provide this type of > buffering? Isn't that the idea behind those? > > > All hypotheses need to be tested. In this case, a test would be to > > check for missing data. If this idea is right, you'll get _all_ the > > data, but you won't be missing characters. > > I did start looking at the data. -- I'm getting weird results. > > I tried this: > > loopzz = 0; > > for (looptwo = 0; looptwo < 100000; looptwo++) { > while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > > }} > > So I'm reading one character at a time. The good news is that loopzz is > exactly 15238 at the end of the routine, which is perfectly correct. I > picked looptwo value out of thin air. > > The weird results come in terms of the values, the data isn't correct at > least in one case. Look here: > > 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > > This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). > But the 0x89 was replaced by 0x2030. Why the heck would the returned value > be 0x2030?? Why is the returned byte completely out of range? Why the > multibyte return? > > From InputStream in the API: > > read > public abstract int read() > throws IOExceptionReads the next byte of data from the > input stream. The value byte is returned as an int in the range 0 to 255. If > no byte is available because the end of the stream has been reached, the > value -1 is returned. This method blocks until input data is available, the > end of the stream is detected, or an exception is thrown. > Value should be 0-255. > > > In my application time is really critical, reading 1 byte at a time is > probably not going to work. > > Thanks Eric & Bob for looking at this. > > Keith > From tjarvi at qbang.org Sat Mar 3 12:52:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 12:52:27 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > update: > > I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now > instead of 3968. > > This makes sense. > > 128 bytes of overhead + 3968 bytes of data = 4096 transfer size > 32 bytes of overhead + 992 bytes of data = 1024 transfer size. > > 1/4 the data = 1/4 the overhead. > > I rearranged my reading like so: > > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. > Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? > > I still can't believe some other layer isn't handling putting those bytes > together all in one stream for me. > The layer for this in Serial land is flow control. Software and hardware flow control prevent the overruns you observe. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:54:41 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:54:41 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <001a01c75dcd$c8802a70$6600a8c0@jbh757ktruws7g> Trent, Thanks for taking the time to reply. > I would expect a 20 meg application is going to have different behavior > with the OS than a smaller application with respect to the kernel memory > managment, schedualing, ... Something subtle could be causing problems. Well, at least I know the VCP drivers, the OS, etc can handle 2mbps reliably. Without hiccuping or dropping bytes. The C++ code works reliably without flow control. > The missing data is typical when not using flow control. When the OS > buffering fills, the hardware will start dropping bytes. I'm actually not getting MISSING data, I'm getting CORRUPTED data. If you look at my most recent post, I'm getting these bad bytes in place of the correct values: 0x2018, 0x2019, x2022, x2030, x201d. Why would is.read() return values not in the range of 0-255 ? Thanks. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 08:59:14 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 07:59:14 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: At 1:19 AM -0500 3/3/07, Keith wrote: >If I do a > >resultz = is.read(cbuf,0,15238); in java with RXTX > >where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > >and where resultz is an int, and cbuf is a char [] cbuf, resultz gets >EXACTLY 3968 bytes the first time called. If I call it multiple times, I get >roughly 11k total(less than what is sent), never more than the 3968 bytes >per is.read() call. > >My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 >bytes. Interesting numerical coincidence is that (max USB transfer) - (what you get) = 4096-3968 = 128 bytes is (almost) the size of the headers needed to transfer that much data. I think what you're seeing is the internal buffering of the USB data stream. You'll need some form of higher-level buffering to smooth that out. All hypotheses need to be tested. In this case, a test would be to check for missing data. If this idea is right, you'll get _all_ the data, but you won't be missing characters. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 09:26:14 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 11:26:14 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Bob, > Interesting numerical coincidence is that (max USB transfer) - (what > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > needed to transfer that much data. I was thinking along the same lines. I don't know USB well, but I do know that those numbers were close enough to warrant investigating the relationship between them. > I think what you're seeing is the internal buffering of the USB data > stream. You'll need some form of higher-level buffering to smooth > that out. Shouldn't the InputStreamReader() and BufferedReader() provide this type of buffering? Isn't that the idea behind those? > All hypotheses need to be tested. In this case, a test would be to > check for missing data. If this idea is right, you'll get _all_ the > data, but you won't be missing characters. I did start looking at the data. -- I'm getting weird results. I tried this: loopzz = 0; for (looptwo = 0; looptwo < 100000; looptwo++) { while (is.ready()) { cbuf[loopzz] = (char) is.read(); loopzz++; }} So I'm reading one character at a time. The good news is that loopzz is exactly 15238 at the end of the routine, which is perfectly correct. I picked looptwo value out of thin air. The weird results come in terms of the values, the data isn't correct at least in one case. Look here: 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). But the 0x89 was replaced by 0x2030. Why the heck would the returned value be 0x2030?? Why is the returned byte completely out of range? Why the multibyte return? >From InputStream in the API: read public abstract int read() throws IOExceptionReads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown. Value should be 0-255. In my application time is really critical, reading 1 byte at a time is probably not going to work. Thanks Eric & Bob for looking at this. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 14:44:50 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 13:44:50 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: Java's "char" type is Unicode. I think what you're seeing is a bug in the byte -> Unicode translation. 0x2018, 0x2019 are the curly open and close quotes. There used to be (and might still be) bugs in the conversion of these in a couple of libc versions. Some of the ASCII -> ISO and ISO -> ASCII routines were a little over-ambitious with respect to handling the open and close quotes, and tried to convert them to the "curly" form inappropriately. Try _not_ casting it to char. Bob At 11:26 AM -0500 3/3/07, Keith wrote: >Bob, > >> Interesting numerical coincidence is that (max USB transfer) - (what >> you get) = 4096-3968 = 128 bytes is (almost) the size of the headers >> needed to transfer that much data. > >I was thinking along the same lines. I don't know USB well, but I do know >that those numbers were close enough to warrant investigating the >relationship between them. > >> I think what you're seeing is the internal buffering of the USB data >> stream. You'll need some form of higher-level buffering to smooth >> that out. > >Shouldn't the InputStreamReader() and BufferedReader() provide this type of >buffering? Isn't that the idea behind those? > >> All hypotheses need to be tested. In this case, a test would be to >> check for missing data. If this idea is right, you'll get _all_ the >> data, but you won't be missing characters. > >I did start looking at the data. -- I'm getting weird results. > >I tried this: > >loopzz = 0; > >for (looptwo = 0; looptwo < 100000; looptwo++) { >while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > >}} > >So I'm reading one character at a time. The good news is that loopzz is >exactly 15238 at the end of the routine, which is perfectly correct. I >picked looptwo value out of thin air. > >The weird results come in terms of the values, the data isn't correct at >least in one case. Look here: > >0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > >This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). >But the 0x89 was replaced by 0x2030. Why the heck would the returned value >be 0x2030?? Why is the returned byte completely out of range? Why the >multibyte return? > >>From InputStream in the API: > >read >public abstract int read() > throws IOExceptionReads the next byte of data from the >input stream. The value byte is returned as an int in the range 0 to 255. If >no byte is available because the end of the stream has been reached, the >value -1 is returned. This method blocks until input data is available, the >end of the stream is detected, or an exception is thrown. >Value should be 0-255. > > >In my application time is really critical, reading 1 byte at a time is >probably not going to work. > >Thanks Eric & Bob for looking at this. > >Keith > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 15:10:11 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 17:10:11 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Bob said ..... > Java's "char" type is Unicode. I think what you're seeing is a bug > in the byte -> Unicode translation. Bob -- I think you hit the nail on the head. I was just coming to the same realization here. I knew that something funny was going on because the same bytes always got "corrupted." I'm pretty sure its in the InputStreamReader() functionality where the conversion junk is happening. Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. I don't know if simply changing the cast is going to work. Since the conversion is happening upstream (pun intended), I don't think my cast is doing this. Also I think the compiler forced me to use the cast. I'm still playing around, and I'll report back once I nail it down. Thanks!! Keith From tjarvi at qbang.org Sat Mar 3 15:59:46 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 15:59:46 -0700 (MST) Subject: [Rxtx] Win64 rxtx Testers? Message-ID: I have compiled win64 binaries of rxtx. Are there any users interested in testing them? If so, I'll look into putting them on the web site. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Mar 3 15:35:06 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 14:35:06 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: Because of this and similar problems, JMRI does all it's serial IO using +only+ byte values. It's a but of a pain, as Java wants to go to char and int types a little too aggressively, but it does solve the "uncontrolled conversions" problems. Bob At 5:10 PM -0500 3/3/07, Keith wrote: >Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > >Bob -- I think you hit the nail on the head. > >I was just coming to the same realization here. I knew that something funny >was going on because the same bytes always got "corrupted." > >I'm pretty sure its in the InputStreamReader() functionality where the >conversion junk is happening. > >Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > >I don't know if simply changing the cast is going to work. Since the >conversion is happening upstream (pun intended), I don't think my cast is >doing this. Also I think the compiler forced me to use the cast. -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mark at mdsh.com Sun Mar 4 11:01:33 2007 From: mark at mdsh.com (Mark Himsley) Date: Sun, 04 Mar 2007 18:01:33 +0000 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: <5C01AC72C200388815C04982@bedroom.mdsh.local> On 03 March 2007 14:38 -0500 Keith wrote: > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT > consistent. Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? It looks like you need to use DataInputStream and DataOutputStream. -- Mark Himsley From tjarvi at qbang.org Sun Mar 4 11:35:08 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 11:35:08 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" > > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > > * Line #21 - Not sure if you need a (TM) mark for > the term "Sun" > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > OK. I'm going through this today. Some groups ask if rxtx could be under their license also. I think this is a good example of why I resist multiple licenses and focus on why the current license may not be usable by them. The RXTX project is a convergence of hobby and commercial interests. I happen to do both right now. The problem with licensing is we have to stay on top of them as they change. Clearly, adding more licenses will not make this easier. I'm acting as the hobby person today. RXTX always favors the hobby people. But as we move forward, I'm going to need to bring this to lawyers at work and explain to them what is going on. Others here may have to do this also. I don't anticipate problems or unexpected changes. The goal is a consistant, comprehendable and usable license as close to what we have now as possible. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 14:52:10 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 14:52:10 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (1/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: I'm breaking this into two parts. I expect the second part will need more attention. Comments first, then the changed material below. On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > Thanks > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. OK. RXTX for consitent use. java should not be capitalized because it does not only mean Sun [TM] Java [TM]. An example of this not meaning Java is when people use RXTX with GCJ. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". There are not any contributors that are in all of RXTX yet but I did update the comment to try to reflect the current situation without making it a nightmare to maintain. I looked to see how the Linux kernel does it as a reference point. > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" The URL can be problematic. I have done so below with a time reference. GNU does not provide version information in their URLS. I picture this being a problem when the version 3 comes out. > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > This will be corrected when the copy is updated to the version linked below. ---------------- begin proposed material involved -------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. ----------------- end proposed material involved -------------------- I'll be looking at the linking issue again next. That should be all that remains other than including the 2.1 version. Let me know if you have problems with anything here. I do not want to dilute the material I post next with these housekeeping tasks. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 16:08:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 16:08:36 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: For those that are wondering what is going on here, this next bit is the meat of the changes. We agreed a long time ago to put this disclaimer in. We did a so so job. It was in rxtx 2.0, not well written, ... So some groups using rxtx that would like to ship rxtx so users don't need to download, install, go to the mail-list to find why it failed, ... Then their legal teams tell them section 5 paragraph 2 is a show stopper. That was never the intent. Now going through what remains... > and might need a (TM) suffix to make Sun happy. Added disclaimer at the ended 'all trademarks belong...' > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. OK. As you can see I was trying to adjust GNU text there for the LGPL. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. used dynamically linked terminology. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". I tried to address this more upfront with an intent statement. Let me know if you have problems with it. I also tried to make it a little more clear what was derived from the GNU solution by moving the link location closer to GNU's suggestion. > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > Thats the intent. Here is the combined fixes. Note that only the material in /*-- --*/ is being touched. The new GPL license is there but unmodified. ------------------------ begin proposed new license ------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. | | An executable that contains no derivative of any portion of RXTX, but | is designed to work with RXTX by being dynamically linked with it, | is considered a "work that uses the Library" subject to the terms and | conditions of the GNU Lesser General Public License. | | The following has been added to the RXTX License to remove | any confusion about linking to RXTX. We want to allow in part what | section 5, paragraph 2 of the LGPL does not permit in the special | case of linking over a controlled interface. The intent is to add a | Java Specification Request or standards body defined interface in the | future as another exception but one is not currently available. | | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface | | As a special exception, the copyright holders of RXTX give you | permission to link RXTX with independent modules that communicate with | RXTX solely through the Sun Microsytems CommAPI interface version 2, | regardless of the license terms of these independent modules, and to copy | and distribute the resulting combined work under terms of your choice, | provided that every copy of the combined work is accompanied by a complete | copy of the source code of RXTX (the version of RXTX used to produce the | combined work), being distributed under the terms of the GNU Lesser General | Public License plus this exception. An independent module is a | module which is not derived from or based on RXTX. | | Note that people who make modified versions of RXTX are not obligated | to grant this special exception for their modified versions; it is | their choice whether to do so. The GNU Lesser General Public License | gives permission to release a modified version without this exception; this | exception also makes it possible to release a modified version which | carries forward this exception. | | You should have received a copy of the GNU Lesser General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA | All trademarks belong to their respective owners. --------------------------------------------------------------------------*/ The original GNU Lesser General Public License Follows. GNU LESSER GENERAL PUBLIC LICENSE Version 2.1, February 1999 Copyright (C) 1991, 1999 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. [This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence the version number 2.1.] Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This license, the Lesser General Public License, applies to some specially designated software packages--typically libraries--of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below. When we speak of free software, we are referring to freedom of use, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish); that you receive source code or can get it if you want it; that you can change the software and use pieces of it in new free programs; and that you are informed that you can do these things. To protect your rights, we need to make restrictions that forbid distributors to deny you these rights or to ask you to surrender these rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library or if you modify it. For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights. We protect your rights with a two-step method: (1) we copyright the library, and (2) we offer you this license, which gives you legal permission to copy, distribute and/or modify the library. To protect each distributor, we want to make it very clear that there is no warranty for the free library. Also, if the library is modified by someone else and passed on, the recipients should know that what they have is not the original version, so that the original author's reputation will not be affected by problems that might be introduced by others. Finally, software patents pose a constant threat to the existence of any free program. We wish to make sure that a company cannot effectively restrict the users of a free program by obtaining a restrictive license from a patent holder. Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license. Most GNU software, including some libraries, is covered by the ordinary GNU General Public License. This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs. When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library. We call this license the "Lesser" General Public License because it does Less to protect the user's freedom than the ordinary General Public License. It also provides other free software developers Less of an advantage over competing non-free programs. These disadvantages are the reason we use the ordinary General Public License for many libraries. However, the Lesser license provides advantages in certain special circumstances. For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License. In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software. For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU operating system, as well as its variant, the GNU/Linux operating system. Although the Lesser General Public License is Less protective of the users' freedom, it does ensure that the user of a program that is linked with the Library has the freedom and the wherewithal to run that program using a modified version of the Library. The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, whereas the latter must be combined with the library in order to run. GNU LESSER GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License Agreement applies to any software library or other program which contains a notice placed by the copyright holder or other authorized party saying it may be distributed under the terms of this Lesser General Public License (also called "this License"). Each licensee is addressed as "you". A "library" means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables. The "Library", below, refers to any such software library or work which has been distributed under these terms. A "work based on the Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term "modification".) "Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library. Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does. 1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) The modified work must itself be a software library. b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change. c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License. d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful. (For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library. In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. 4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange. If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code. 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables. When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law. If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.) Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself. 6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications. You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things: a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.) b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. c) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution. d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place. e) Verify that the user has already received a copy of these materials or that you have already sent this user a copy. For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute. 7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things: a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above. b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work. 8. You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 9. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Library (or any work based on the Library), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Library or works based on it. 10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties with this License. 11. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply, and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 12. If the distribution and/or use of the Library is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Library under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 13. The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation. 14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Libraries If you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the ordinary General Public License). To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Also add information on how to contact you by electronic and paper mail. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the library, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the library `Frob' (a library for tweaking knobs) written by James Random Hacker. , 1 April 1990 Ty Coon, President of Vice That's all there is to it! ------------------------ end of proposed license ------------------ -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sun Mar 4 16:26:04 2007 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 04 Mar 2007 17:26:04 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <45EB558C.3010609@cox.net> Bob Jacobsen wrote: > Because of this and similar problems, JMRI does all it's serial IO > using +only+ byte values. It's a but of a pain, as Java wants to go > to char and int types a little too aggressively, but it does solve > the "uncontrolled conversions" problems. Anytime that you are reading bytes of data that is not printable, unicode text, in Java, you really need to stay away from the Readers. Use input stream only, or you will see unicode valued byte groups converted to unicode "char" values. Gregg Wonderly From joachim at buechse.de Mon Mar 5 04:23:48 2007 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 5 Mar 2007 12:23:48 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> The behaviour is exactly what you asked for in you code. is = new BufferedReader(new InputStreamReader(port.getInputStream())); Readers return Text (ie unicode chars) not bytes. You instantiate the InputStreamReader without saying which charset you want, which means "platform default". As this is on Windows, it will convert Windows characters to equivalent unicode characters. If you want to read bytes, read bytes not Text. Reading bytes is done with InputStream and BufferedInputStream. BTW: The InputStream and Reader methods that read arrays are not guarenteed to fill up the array. You always have to check what you really got, and advance your index accordingly. A typical "read up to 32k" method looks like this: InputStream is= ... // -- determine the max buffer size int len= is.available(); if (len == 0) { len= 32 * 1024; } // -- read all available data byte[] buffer= new byte[len]; int pos= 0; int read; do { read= is.read(buffer, pos, buffer.length - pos); pos= pos + read; } while (read != -1 && pos < buffer.length); Best regards, Joachim --- Joachim B?chse Phone: +41 44 500 2604 Buechse Consulting Hadlaubsteig 2 CH-8006 Z?rich On 03.03.2007, at 23:10, Keith wrote: > Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > > Bob -- I think you hit the nail on the head. > > I was just coming to the same realization here. I knew that > something funny > was going on because the same bytes always got "corrupted." > > I'm pretty sure its in the InputStreamReader() functionality where the > conversion junk is happening. > > Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > > I don't know if simply changing the cast is going to work. Since the > conversion is happening upstream (pun intended), I don't think my > cast is > doing this. Also I think the compiler forced me to use the cast. > > I'm still playing around, and I'll report back once I nail it down. > > Thanks!! > > Keith > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Mon Mar 5 07:25:46 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 05 Mar 2007 08:25:46 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> Message-ID: <45EC286A.8060608@cox.net> Joachim Buechse wrote: > BTW: The InputStream and Reader methods that read arrays are not > guarenteed to fill up the array. You always have to check what you > really got, and advance your index accordingly. A typical "read up to > 32k" method looks like this: > > InputStream is= ... > // -- determine the max buffer size > int len= is.available(); > if (len == 0) { > len= 32 * 1024; > } > // -- read all available data > byte[] buffer= new byte[len]; > int pos= 0; > int read; > do { > read= is.read(buffer, pos, buffer.length - pos); > pos= pos + read; > } while (read != -1 && pos < buffer.length); > My preferred structure is. byte arr[ len ]; int cnt; int off = 0; while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { off += cnt; } This keeps you from adding -1 to pos when the read returns -1. It also skips out when the read is 0 bytes which, is not a described EOF in InputStream java docs, but is a condition I want to be aware of. Gregg Wonderly From joachim at buechse.de Tue Mar 6 02:52:58 2007 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 6 Mar 2007 10:52:58 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <45EC286A.8060608@cox.net> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: The code I copied was from a file resource reader, it shouldn't really be applied to networking/external IO code. Mea culpa. However aborting when you get 0 from read is not always what you want either (you kind of indicated that already). Some unix java implementations will return 0 if the kernel read was aborted with EINTER, which is rarely the point where you want to abort your read - at least not without further checks. A "complete" solution always depends on the events you need to handle and the time the total read could take in reality. In some cases it's worth checking Thread.isInterrupted() in the loop, some code re-loops on 0 but only a limited number of times, some check a total timeout limit, etc... Best regards, Joachim On 05.03.2007, at 15:25, Gregg Wonderly wrote: > My preferred structure is. > > byte arr[ len ]; > int cnt; > int off = 0; > while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { > off += cnt; > } > > This keeps you from adding -1 to pos when the read returns -1. It > also skips > out when the read is 0 bytes which, is not a described EOF in > InputStream java > docs, but is a condition I want to be aware of. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Mar 6 14:47:44 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 Mar 2007 14:47:44 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: Just FYI, rxtx will usually not break out on EINTER. The code in the native library usually does something close to this: do { read(...) } while ( !done && errno==EINTR ); Obviously there is a little more involved but it will retry on EINTER if not done. On Tue, 6 Mar 2007, Joachim Buechse wrote: > The code I copied was from a file resource reader, it shouldn't > really be applied to networking/external IO code. Mea culpa. > > However aborting when you get 0 from read is not always what you want > either (you kind of indicated that already). Some unix java > implementations will return 0 if the kernel read was aborted with > EINTER, which is rarely the point where you want to abort your read - > at least not without further checks. A "complete" solution always > depends on the events you need to handle and the time the total read > could take in reality. In some cases it's worth checking > Thread.isInterrupted() in the loop, some code re-loops on 0 but only > a limited number of times, some check a total timeout limit, etc... > > Best regards, > Joachim > > On 05.03.2007, at 15:25, Gregg Wonderly wrote: >> My preferred structure is. >> >> byte arr[ len ]; >> int cnt; >> int off = 0; >> while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { >> off += cnt; >> } >> >> This keeps you from adding -1 to pos when the read returns -1. It >> also skips >> out when the read is 0 bytes which, is not a described EOF in >> InputStream java >> docs, but is a condition I want to be aware of. >> >> Gregg Wonderly >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 gjhanna at gmail.com Thu Mar 8 13:42:52 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Fri, 9 Mar 2007 09:42:52 +1300 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? Message-ID: I've just struck an issue using rxtx in a multi-threaded environment: If I have 3 threads trying to open *the same* comm-port I get a deadlock in CommPortIdentifier.open If I have just 2, it works fine - I get a PortInUseException which is nice and I can handle it. The 3 thread->deadlock thing is causing me issues. (Sample code below). This is from the java thread-dump Found one Java-level deadlock: ============================= "Thread-2": waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object ), which is held by "Thread-1" "Thread-1": waiting to lock monitor 0x0003e9cc (object 0x2450e108, a gnu.io.CommPortIdentifier), which is held by "Thread-2" Java stack information for the threads listed above: =================================================== "Thread-2": at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:329) - waiting to lock <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) "Thread-1": at java.lang.Object.wait(Native Method) - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) - locked <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) (Apart from this, rxtx is working fantastically for us). I'm thinking I'll have to implement some sort of locking mechanism that *doesn't* use java synchronization to prevent this situation. (Which doesn't sound like a good idea to me). Any ideas? Thanks, Greg Hanna ============= RXTXLockTest.java ======================================== import gnu.io.CommPort; import gnu.io.CommPortIdentifier; /** * @author Greg Hanna * Minimal code to create a deadlock with rxtx in multithreaded open */ public class RXTXLockTest { public static void main(String[] args) { try { CommPortIdentifier cpiCom1 = CommPortIdentifier.getPortIdentifier ("COM14"); OpenThread t1 = new OpenThread (" one ", cpiCom1); OpenThread t2 = new OpenThread (" two ", cpiCom1); OpenThread t3 = new OpenThread (" 003 ", cpiCom1); t1.start(); t2.start(); t3.start(); // comment this out and it runs with (expected) PortInUseException } catch (Exception e) { e.printStackTrace(); } } } class OpenThread extends Thread { String name; CommPortIdentifier cpi; CommPort cp; public OpenThread (String name, CommPortIdentifier cpi) { this.name = name; this.cpi = cpi; System.out.println (System.currentTimeMillis() + name + " thread created"); } public void run () { try { System.out.println (System.currentTimeMillis() + name + " opening"); cp = cpi.open(name, 2000); System.out.println (System.currentTimeMillis() + name + " opened - sleeping"); sleep (2000); // do the serial comms with the device. System.out.println (System.currentTimeMillis() + name + " slept - closing"); cp.close(); System.out.println (System.currentTimeMillis() + name + " closed - exiting"); } catch (Exception e) { System.out.println ("Error in thread: " + name ); e.printStackTrace(); } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070308/d9a163c5/attachment-0010.html From eu259473 at tele2.it Fri Mar 9 02:46:20 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 09 Mar 2007 10:46:20 +0100 Subject: [Rxtx] rxtx: tru64 unix make fails Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070309/3b654523/attachment-0010.html From lyon at docjava.com Fri Mar 9 03:58:32 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 Mar 2007 05:58:32 -0500 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi All, The deadlock issue is one that I have been thinking about for some time now. It seems to me that we need a resource manager that enables assignment to a known process. The one thing that seems important about serial ports is that two applications should not use the same serial port at the same time. When this happens, it throws an exception. OK. The exception is a response to a lock condition that arises from an unavailable resource. An abstract implementation (not born of native methods) might assign a serial port to an application, until the application releases it (or is forced to release it by some kill mechanism). Some resources (like a registry) can be reused. But others, like the serial port, cannot. In the case of the serial port, we would like, I think, to have the flyweight design pattern without sharing and with object assignment tracking. A means of breaking deadlock (like a leasing mechanism) seems very useful, to me. My guess is that we can serialize the state of the Parametric Singleton Pattern (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) into the Preferences of the System. Preferences.systemRoot() might help with that. When a resource is checked out, the lease time and owner are listed. A thread that does this can be killed, but applications outside of Java are problematic. There is a compelling problem here. It is not just serial ports. Sound cards, cameras, microphones, files, tape drives, etc. All are consumed resources that are assigned to an application (or user) and deprive other applications, or users, from use. What, if anything, should we do? At present we throw PortInUseExceptions. Is that it? Can we do better? OK, the port is in use. Now what? Do I have to be root to go remove lock files and kill applications? Is there a better way? Thanks! - Doug >I've just struck an issue using rxtx in a multi-threaded environment: > >If I have 3 threads trying to open *the same* >comm-port I get a deadlock in >CommPortIdentifier.open >If I have just 2, it works fine - I get a >PortInUseException which is nice and I can >handle it. > >The 3 thread->deadlock thing is causing me issues. >(Sample code below). > >This is from the java thread-dump > >Found one Java-level deadlock: >============================= >"Thread-2": > waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), > which is held by "Thread-1" >"Thread-1": > waiting to lock monitor 0x0003e9cc (object >0x2450e108, a gnu.io.CommPortIdentifier ), > which is held by "Thread-2" > >Java stack information for the threads listed above: >=================================================== >"Thread-2": > at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) > - waiting to lock <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) >"Thread-1": > at java.lang.Object.wait(Native Method) > - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) > - locked <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) > > >(Apart from this, rxtx is working fantastically for us). > >I'm thinking I'll have to implement some sort of >locking mechanism that *doesn't* use java >synchronization to prevent this situation. >(Which doesn't sound like a good idea to me). > >Any ideas? > >Thanks, > >Greg Hanna > >============= RXTXLockTest.java ======================================== > >import gnu.io.CommPort; >import gnu.io.CommPortIdentifier; > >/** > * @author Greg Hanna > * Minimal code to create a deadlock with rxtx in multithreaded open > */ >public class RXTXLockTest { > ? > ?public static void main(String[] args) { > ?try { > ?CommPortIdentifier cpiCom1 = >CommPortIdentifier.getPortIdentifier ("COM14"); > ?OpenThread t1 = new OpenThread (" one ", cpiCom1); > ?OpenThread t2 = new OpenThread (" two ", cpiCom1); > ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); > ?t1.start(); > ?t2.start(); > ?t3.start(); // comment this out >and it runs with (expected) PortInUseException > ?} catch (Exception e) { > ?e.printStackTrace(); > ?} > ?} >} > >class OpenThread extends Thread { > ?String name; > ?CommPortIdentifier cpi; > ?CommPort cp; > ?public OpenThread (String name, CommPortIdentifier cpi) { > ? this.name = name; > ?this.cpi = cpi; > ?System.out.println >(System.currentTimeMillis() + name + " thread >created"); > ?} > ?public void run () { > ?try { > ?System.out.println >(System.currentTimeMillis() + name + " opening"); > ?cp = cpi.open(name, 2000); > ?System.out.println >(System.currentTimeMillis() + name + " opened - >sleeping"); > ?sleep (2000); // do the serial comms with the device. > ?System.out.println >(System.currentTimeMillis() + name + " slept - >closing"); > ?cp.close(); > ?System.out.println >(System.currentTimeMillis() + name + " closed - >exiting"); > ?} catch (Exception e) { > System.out.println ("Error in thread: " + name ); > ?e.printStackTrace(); > ?} > ?} >} > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Mar 9 06:37:45 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 Mar 2007 06:37:45 -0700 (MST) Subject: [Rxtx] rxtx: tru64 unix make fails In-Reply-To: References: Message-ID: On Fri, 9 Mar 2007, "Giuseppe Marchese" wrote: > Sorry for delay. > ? > This is log for ./configure and make > error. > ? > thanks for attention > ? > Make: '%.java,$(TOP)/$(CLASSDEST)/%.class,$(wildcard $(SPATH)/*.java)': extra chars.? > Stop. > Hi Giuseppe You need to use GNU make with the Makefile. I suspect the tru64 make is not happy with those rules. > configure: exit 0 Looks like configure is fairly happy. From tjarvi at qbang.org Sat Mar 10 07:43:51 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 07:43:51 -0700 (MST) Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi Doug I have very little time to look into this further but what we could do is open up an rxtx 3 devel branch in which a proof of concept could be worked on. It could be the proof of concept for a JSR others including Sun could look at/work on or parts of it could be recycled in a JSR. I'm working very hard on rxtx right now but it does not show. I'm looking at win64, mac intel/ppc, usb bluetooth and usb serial dongles. Some are going to be more tested than others but they are all on the plate. I'll be pushing all the fixes upstream when they are done. So I'm very busy in 2.1 but we could open a new branch. On Fri, 9 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > The deadlock issue is one that I have been thinking about > for some time now. > It seems to me that we need a resource manager that enables assignment > to a known process. > > The one thing that seems important about serial > ports is that two applications should not use the > same serial port at the same time. When this > happens, it throws an exception. > OK. > > The exception is a response to a lock condition that > arises from an unavailable resource. > > An abstract implementation (not born of native methods) might > assign a serial port to an application, until the > application releases it (or is forced to release > it by some kill mechanism). > > Some resources (like a registry) can be reused. > But others, like the serial port, > cannot. > > In the case of the serial port, we would like, I think, to > have the flyweight design pattern > without sharing and with object assignment tracking. > A means of breaking deadlock (like a leasing > mechanism) seems very useful, to me. > > My guess is that we can serialize the state of the Parametric Singleton Pattern > (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) > into the Preferences of the System. Preferences.systemRoot() might help > with that. When a resource is checked out, the lease time and owner are > listed. A thread that does this can be killed, but applications outside of Java > are problematic. > > There is a compelling problem here. It is not just serial ports. > Sound cards, cameras, microphones, files, tape drives, etc. All are consumed > resources that are assigned to an application (or > user) and deprive other applications, > or users, from use. > > What, if anything, should we do? At present we throw PortInUseExceptions. > Is that it? > Can we do better? > OK, the port is in use. Now what? > Do I have to be root to go remove lock files and kill applications? > Is there a better way? > > Thanks! > - Doug > >> I've just struck an issue using rxtx in a multi-threaded environment: >> >> If I have 3 threads trying to open *the same* >> comm-port I get a deadlock in >> CommPortIdentifier.open >> If I have just 2, it works fine - I get a >> PortInUseException which is nice and I can >> handle it. >> >> The 3 thread->deadlock thing is causing me issues. >> (Sample code below). >> >> This is from the java thread-dump >> >> Found one Java-level deadlock: >> ============================= >> "Thread-2": >> waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), >> which is held by "Thread-1" >> "Thread-1": >> waiting to lock monitor 0x0003e9cc (object >> 0x2450e108, a gnu.io.CommPortIdentifier ), >> which is held by "Thread-2" >> >> Java stack information for the threads listed above: >> =================================================== >> "Thread-2": >> at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) >> - waiting to lock <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> "Thread-1": >> at java.lang.Object.wait(Native Method) >> - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) >> - locked <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> >> >> (Apart from this, rxtx is working fantastically for us). >> >> I'm thinking I'll have to implement some sort of >> locking mechanism that *doesn't* use java >> synchronization to prevent this situation. >> (Which doesn't sound like a good idea to me). >> >> Any ideas? >> >> Thanks, >> >> Greg Hanna >> >> ============= RXTXLockTest.java ======================================== >> >> import gnu.io.CommPort; >> import gnu.io.CommPortIdentifier; >> >> /** >> * @author Greg Hanna >> * Minimal code to create a deadlock with rxtx in multithreaded open >> */ >> public class RXTXLockTest { >> ? >> ?public static void main(String[] args) { >> ?try { >> ?CommPortIdentifier cpiCom1 = >> CommPortIdentifier.getPortIdentifier ("COM14"); >> ?OpenThread t1 = new OpenThread (" one ", cpiCom1); >> ?OpenThread t2 = new OpenThread (" two ", cpiCom1); >> ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); >> ?t1.start(); >> ?t2.start(); >> ?t3.start(); // comment this out >> and it runs with (expected) PortInUseException >> ?} catch (Exception e) { >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> class OpenThread extends Thread { >> ?String name; >> ?CommPortIdentifier cpi; >> ?CommPort cp; >> ?public OpenThread (String name, CommPortIdentifier cpi) { >> ? this.name = name; >> ?this.cpi = cpi; >> ?System.out.println >> (System.currentTimeMillis() + name + " thread >> created"); >> ?} >> ?public void run () { >> ?try { >> ?System.out.println >> (System.currentTimeMillis() + name + " opening"); >> ?cp = cpi.open(name, 2000); >> ?System.out.println >> (System.currentTimeMillis() + name + " opened - >> sleeping"); >> ?sleep (2000); // do the serial comms with the device. >> ?System.out.println >> (System.currentTimeMillis() + name + " slept - >> closing"); >> ?cp.close(); >> ?System.out.println >> (System.currentTimeMillis() + name + " closed - >> exiting"); >> ?} catch (Exception e) { >> System.out.println ("Error in thread: " + name ); >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 mm at UDel.Edu Sat Mar 10 14:48:32 2007 From: mm at UDel.Edu (Mike Markowski) Date: Sat, 10 Mar 2007 16:48:32 -0500 Subject: [Rxtx] rxtx and Sun's comm api Message-ID: <45F327B0.2060004@udel.edu> Hi all, I joined the list a few days ago and apologize for what is likely a frequently asked question, though I haven't yet found it anywhere. I learned about rxtx.org through the readme on Sun's version 2 of their comms api. They give recommendations in that readme regarding how a better comms api should be written. Is this the aim of rxtx.org? I wrote an app on my linux box using the Sun comms api (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the fact that only linux and Solaris are supported. So I'm glad to find rxtx.org and am just reading up on how make the conversion so Windows users will be able to run the program as well. At the same time I'm just curious if rxtx.org and Sun are both heading in the same direction. Thanks for any background or historical info. Feel free to point me to any www pages if my googling has just completely missed the target! Thanks again, Mike From tjarvi at qbang.org Sat Mar 10 15:35:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 15:35:25 -0700 (MST) Subject: [Rxtx] rxtx and Sun's comm api In-Reply-To: <45F327B0.2060004@udel.edu> References: <45F327B0.2060004@udel.edu> Message-ID: On Sat, 10 Mar 2007, Mike Markowski wrote: > Hi all, > > I joined the list a few days ago and apologize for what is likely a > frequently asked question, though I haven't yet found it anywhere. I > learned about rxtx.org through the readme on Sun's version 2 of their > comms api. They give recommendations in that readme regarding how a > better comms api should be written. Is this the aim of rxtx.org? > > I wrote an app on my linux box using the Sun comms api > (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the > fact that only linux and Solaris are supported. So I'm glad to find > rxtx.org and am just reading up on how make the conversion so Windows > users will be able to run the program as well. At the same time I'm > just curious if rxtx.org and Sun are both heading in the same direction. > > Thanks for any background or historical info. Feel free to point me to > any www pages if my googling has just completely missed the target! > I do not have any news (good or bad) concerning RXTX and Sun working together but perhaps others here do. The main goal of RXTX is to expose POSIX termios interfaces to java users. The future support of javax.comm is questionable. We do not have resources for everything. gnu.io (RXTX 2.1) will be supported going forward and functions the same as CommAPI 2.0. If you have control of the source code you are working with, I would not advise using CommAPI 2.0 javax.comm. We do support CommAPI 2.0 javax.comm for older applications but I do not think that will last much longer for practical reasons. The download interest in CommAPI 2.0 javax.comm support is becomming negligible on this end. There has been discussion of a JSR effort but I do not know of any status change since it was mentioned. One problem with a JSR is that even a light weight process is going to be difficult for RXTX at this time. Maybe that will change in the future but then again it may not. For now, we are just going forward 'as is' in rxtx 2.1 with package gnu.io while trying as a secondary effort to backport the changes to rxtx 2.0 for javax.comm support for users that do not have a choice. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Mar 11 07:19:40 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 11 Mar 2007 08:19:40 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: Hi All, I have been a proponent of a JSR that makes use of RXTX. I have executed the proper agreements with Sun. At this point we are in the: Early Draft Review of Draft Specifications Stage. The best thing to do is to enter the quiet period and create a specification. The question of exactly how we, as a group, want to approach this problem, remains open. Typically, we should have both a specification and a reference implementation. Thus, it would be to our best advantage to have a nice, stable, cross platform RXTX distro that adheres to the groups specification. Now, from a specification standpoint, my personal view on the matter is that we create a series of interfaces, with nice documentation (or at least javadoc). Is this a good idea? Should we have a pure interface specification for the communication API? There are several issues, in my mind, which still weigh on us. Hot-pluggable dongles, long discovery process on pop-up ports, lack of uniformity on device names, lack of uniformity on locking, a precise understanding of how the SerialPortResourceManager works (or even if we should have one). The more questions we answer in our reference implementation, the better our specification will get. RXTX is a good working prototype, but, I don't know if that is what we want to use for a specification. Here is what I have for a CommPortInterface: */ public interface CommPortInterface { /** * @return a string representation of this port. */ String toString(); /** * Gets the name of the communications port. This name should correspond to * something the user can identify, like the label on the hardware. * @return name of the port */ String getName(); /** * @return an input stream that can be used to read data from the * communications port. If the port doesn't support reading data, this * method returns null. *

* The blocking behaviour of this input stream depends on the threshold * and timeout values, as shown below for a read buffer size of n * bytes: * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ThresholdTimeoutBlocking behaviour
StateValueStateValue
disableddisabledblock until data is available
enabledm bytesdisabledblock until min(m, n) bytes are available
disabledenabledt msblock for t ms or until data is available
enabledm bytesenabledt msblock for t ms or until min(m, n) bytes are * available
* @throws java.io.IOException */ InputStream getInputStream() throws IOException; /** * @return an output stream that can be used to send data to the * communications port. If the port doesn't support sending data, this * method returns null. * @throws java.io.IOException */ OutputStream getOutputStream() throws IOException; /** * Closes this communications port. * All PortOwnershipListeners will be? * notified of this change of ownership. Further method calls on this? * object will throw IllegalStateException. Further calls on the? * associated InputStream or OutputStream will throw IOException. *

* Close does not block. Undelivered data is discarded. Blocked read and? * write operations are aborted if the underlying operating systems? * supports an IO abort mechanism. To await the delivery of undelivered? * data call OutputStream.flush() or OutputStream.close() before calling? * Port.close(). */ void close(); /** * Enables receive threshold. * When the specified threshold number of bytes are retrieved, read will * return immediately. * * @param thresh the number of bytes in the input buffer * @throws gnu.io.UnsupportedCommOperationException * if receive threshold is * not supported by the driver * @see #disableReceiveThreshold */ void enableReceiveThreshold(int thresh) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive threshold. * * @see #enableReceiveThreshold */ void disableReceiveThreshold(); /** * @return true if receive threshold is enabled. * * @see #enableReceiveThreshold */ boolean isReceiveThresholdEnabled(); /** * @return the receive threshold value. If receive threshold is diabled * or not supported, this value is meaningless. * * @see #enableReceiveThreshold */ int getReceiveThreshold(); /** * Enables receive timeout. * When the specified number of milliseconds have elapsed, read will * return immediately. * * @param rcvTimeout the number of milliseconds to block for * @throws gnu.io.UnsupportedCommOperationException * if receive timeout is * not supported by the driver * @see #disableReceiveTimeout */ void enableReceiveTimeout(int rcvTimeout) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive timeout. * * @see #enableReceiveTimeout */ void disableReceiveTimeout(); /** * @return true if receive timeout is enabled. * * @see #enableReceiveTimeout */ boolean isReceiveTimeoutEnabled(); /** * @return the receive timeout value. If receive timeout is diabled * or not supported, this value is meaningless. * * @see #enableReceiveTimeout */ int getReceiveTimeout(); /** * Enables receive framing. * The supplied byte value in the input suggests the end of the received * frame, and read returns immediately. Only the low 8 bits of the * supplied value are significant. * * @param framingByte the frame delimiter * @throws gnu.io.UnsupportedCommOperationException * if receive framing is * not supported by the driver * @see #disableReceiveFraming */ void enableReceiveFraming(int framingByte) throws UnsupportedCommOperationException; /** * Disables receive framing. * * @see #enableReceiveFraming */ void disableReceiveFraming(); /** * @return true if receive framing is enabled. * * @see #enableReceiveFraming */ boolean isReceiveFramingEnabled(); /** * @return true if receive framing byte. If receive framing is diabled * or not supported, this value is meaningless. * * @see #enableReceiveFraming */ int getReceiveFramingByte(); /** * Sets the input buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setInputBufferSize(int size); /** * @return the input buffer size. * The driver may choose not to report correct values. */ int getInputBufferSize(); /** * Sets the output buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setOutputBufferSize(int size); /** * @return the output buffer size. * The driver may choose not to report correct values. */ int getOutputBufferSize(); } What do you think of that? Note the wishy washy nature of the spec: The driver may choose to ignore this method. Is that good enough for us? Thanks! - Doug From ra85551 at gmail.com Sun Mar 11 08:44:45 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Sun, 11 Mar 2007 17:44:45 +0300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hello, world! I am writing application that communicates with modem via AT commands. My OS is Linux Kubuntu Feisty Herd, to ensure that my application will run properly under Windows XP I installed VMWare server. When I tried to send AT command and evaluate modem answer under WinXP @ VMWare server, I actually didn't receive anything. I think that VM settings are right, because I do can communicate with modem by using standard HyperTerminall as well as I can do on native Windows. So, why RXTX doesn't work under VM, but works under Linux and pure Windows XP (i tested it there) well? The send/receive method code follows. private String sendATCommand(String command, final String waitFor, final boolean isRegex, boolean isAddCRLF, long timeout) throws BeaconConnectException { final long POLL_PERIOD = 100; final int BUFFER_SIZE = 512; final byte[] buffer = new byte[BUFFER_SIZE]; final InputStream serialInput; final OutputStream serialOutput; try { serialInput = serialPort.getInputStream(); if (command != null) { serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } } catch (IOException e) { throw new MyException("serial I/O error"); } TimerTask task = new TimerTask() { int offset = 0; int bytesRead; public synchronized void run() { try { if (serialInput.available() > 0) { bytesRead = serialInput.read(buffer, offset, BUFFER_SIZE - offset); } else { return; } } catch (IOException e) { // do nothing - maybe next time we'll read something } offset += bytesRead; if (waitFor != null) { String temporary = new String(buffer, 0, offset).trim(); if (isRegex && temporary.matches(waitFor) || temporary.contains(waitFor)) { cancel(); notify(); } } } }; Timer timer = new Timer(); timer.schedule(task, POLL_PERIOD, POLL_PERIOD); synchronized (task) { try { task.wait(timeout); task.cancel(); } catch (InterruptedException e) { } } //Cut off leading and trailing CRs, LFs and zeroes String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); System.out.println(response); return response; } -- Pavel Parkhomenko From tjarvi at qbang.org Sun Mar 11 11:48:22 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:48:22 -0600 (MDT) Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: On Sun, 11 Mar 2007, Pavel Parkhomenko wrote: > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. > > private String sendATCommand(String command, final String waitFor, > final boolean isRegex, boolean isAddCRLF, long timeout) > throws BeaconConnectException > { > final long POLL_PERIOD = 100; > final int BUFFER_SIZE = 512; > final byte[] buffer = new byte[BUFFER_SIZE]; > final InputStream serialInput; > final OutputStream serialOutput; > try > { > serialInput = serialPort.getInputStream(); > if (command != null) > { > serialOutput = serialPort.getOutputStream(); > if (isAddCRLF) > { > command += "\r\n"; > } > System.out.println(command); > serialOutput.write(command.getBytes()); > } > } > catch (IOException e) > { > throw new MyException("serial I/O error"); > } > > TimerTask task = new TimerTask() > { > int offset = 0; > int bytesRead; > public synchronized void run() > { > try > { > if (serialInput.available() > 0) > { > bytesRead = serialInput.read(buffer, offset, > BUFFER_SIZE - offset); > } > else > { > return; > } > } > catch (IOException e) > { > // do nothing - maybe next time we'll read something > } > offset += bytesRead; > if (waitFor != null) > { > String temporary = new String(buffer, 0, offset).trim(); > if (isRegex && temporary.matches(waitFor) || > temporary.contains(waitFor)) > { > cancel(); > notify(); > } > } > } > }; > > Timer timer = new Timer(); > timer.schedule(task, POLL_PERIOD, POLL_PERIOD); > synchronized (task) { > try > { > task.wait(timeout); > task.cancel(); > } > catch (InterruptedException e) > { > } > } > //Cut off leading and trailing CRs, LFs and zeroes > String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); > System.out.println(response); > return response; > } > > > Hi Pavel VMWare should not be a problem. I've used it in the past - though not with a modem. Make sure nothing else is using the modem. Then look in the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an example that should work. Note that modems could care less what OS is on top. If you are trying to match new lines to the OS and sending it to the mode for AT commands, thats probably a mistake. Also it would not hurt to print out the individual bytes that you are sending to make sure they did not get mangled along the path. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 11:55:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:55:48 -0600 (MDT) Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: On Sun, 11 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > I have been a proponent of a JSR that makes > use of RXTX. I have executed the proper agreements with Sun. > > At this point we are in the: > Early Draft Review of Draft Specifications Stage. > > The best thing to do is to enter the quiet period and create > a specification. The question of exactly how we, as a group, > want to approach this problem, remains open. > > Typically, we should have both a specification and a reference > implementation. Thus, it would be to our best advantage to have > a nice, stable, cross platform RXTX distro that adheres to the > groups specification. > > Now, from a specification standpoint, my personal view on the matter is > that we create a series of interfaces, with nice documentation (or at least > javadoc). > > Is this a good idea? Should we have a pure interface specification for > the communication API? > > There are several issues, in my mind, which still weigh on us. > Hot-pluggable dongles, long discovery process on pop-up ports, > lack of uniformity on device names, lack of uniformity on locking, > a precise understanding of how the SerialPortResourceManager > works (or even if we should have one). > > The more questions we answer in our reference implementation, the > better our specification will get. RXTX is a good working prototype, > but, I don't know if that is what we want to use for a specification. > > Here is what I have for a CommPortInterface: > */ > public interface CommPortInterface { Hi Doug, I can start going through the method interfaces later this week and giving feedback. I would suggest that the JSR should not be too generic in nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel drivers that intend to look like EIA232 ports at the kernel driver level. some ideas: EIA232PortInterface TermiosInterface SerialPortInterface Something that differentiates this from thing like USB, I2C, ... which should not have to deal with legacy serial claiming to be the comm api. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 12:52:19 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 12:52:19 -0600 (MDT) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: No news is good news with these posts. I'll start the process of pinging legal a week from Monday on my end if nobody has objections to the proposal. I just want to make sure everyone has time to raise objections. Obviously, anyone can fork from a previous version if they don't like the new license. I suspect we can avoid that though. On Sun, 4 Mar 2007, Trent Jarvi wrote: > > For those that are wondering what is going on here, this > next bit is the meat of the changes. We agreed a long time > ago to put this disclaimer in. We did a so so job. It was > in rxtx 2.0, not well written, ... So some groups using > rxtx that would like to ship rxtx so users don't need to > download, install, go to the mail-list to find why it failed, > ... Then their legal teams tell them section 5 paragraph 2 > is a show stopper. > > That was never the intent. > > > Now going through what remains... > >> and might need a (TM) suffix to make Sun happy. > > Added disclaimer at the ended 'all trademarks belong...' > >> * Line #15ff - static vs. dynamic linking - you did >> not transcribe the text from the "controlled >> interface exception" when writing this text - and >> this was good so, because these terms originally >> refer to the GPL rather than the LGPL. I think though, >> that these 4 lines are the most important ones and >> should thus be really really clear. I hope that I >> meet your original intent with the following >> suggestions: >> 1.) Instead of "A program.." it would be better to >> say "An exectuable.." in order to be closer to >> the LGPL text. > > OK. As you can see I was trying to adjust GNU text there > for the LGPL. > >> 2.) It would be better to say .. "by being dynamically >> linked with it" to clearly indicate that dynamic >> linking is meant. The matter of compilation is >> already covered by the LGPL so mentioning it again >> just leads to confusion. > > used dynamically linked terminology. > >> 3.) It would be better to say .. "is considered a >> work that uses the library in contrast to section >> 5 of the LGPL, so the terms of the LGPL do not >> apply to the resulting executable". > > I tried to address this more upfront with an intent statement. > Let me know if you have problems with it. I also tried to > make it a little more clear what was derived from the GNU > solution by moving the link location closer to GNU's suggestion. > >> >> Note that LGPL section 5 says: ..."is called a >> "work that uses the Library". Such a work, in isolation, >> is not a derivative work of the Library, and therefore >> falls outside the scope of this License." >> The next paragraph of the LGPL is exactly the problematic >> one that I hope is clarified by the exception terms you >> give. >> > > Thats the intent. Here is the combined fixes. Note that only the > material in /*-- --*/ is being touched. The new GPL license is > there but unmodified. > > > ------------------------ begin proposed new license ------------------- > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Lesser General Public > | License as published by the Free Software Foundation; either > | version 2.1 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Lesser General Public License for more details. > | > | An executable that contains no derivative of any portion of RXTX, but > | is designed to work with RXTX by being dynamically linked with it, > | is considered a "work that uses the Library" subject to the terms and > | conditions of the GNU Lesser General Public License. > | > | The following has been added to the RXTX License to remove > | any confusion about linking to RXTX. We want to allow in part what > | section 5, paragraph 2 of the LGPL does not permit in the special > | case of linking over a controlled interface. The intent is to add a > | Java Specification Request or standards body defined interface in the > | future as another exception but one is not currently available. > | > | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface > | > | As a special exception, the copyright holders of RXTX give you > | permission to link RXTX with independent modules that communicate with > | RXTX solely through the Sun Microsytems CommAPI interface version 2, > | regardless of the license terms of these independent modules, and to copy > | and distribute the resulting combined work under terms of your choice, > | provided that every copy of the combined work is accompanied by a complete > | copy of the source code of RXTX (the version of RXTX used to produce the > | combined work), being distributed under the terms of the GNU Lesser General > | Public License plus this exception. An independent module is a > | module which is not derived from or based on RXTX. > | > | Note that people who make modified versions of RXTX are not obligated > | to grant this special exception for their modified versions; it is > | their choice whether to do so. The GNU Lesser General Public License > | gives permission to release a modified version without this exception; this > | exception also makes it possible to release a modified version which > | carries forward this exception. > | > | You should have received a copy of the GNU Lesser General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > | All trademarks belong to their respective owners. > --------------------------------------------------------------------------*/ > > The original GNU Lesser General Public License Follows. > > > GNU LESSER GENERAL PUBLIC LICENSE > Version 2.1, February 1999 > > Copyright (C) 1991, 1999 Free Software Foundation, Inc. > 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > Everyone is permitted to copy and distribute verbatim copies > of this license document, but changing it is not allowed. > > [This is the first released version of the Lesser GPL. It also counts > as the successor of the GNU Library Public License, version 2, hence > the version number 2.1.] > > Preamble > > The licenses for most software are designed to take away your > freedom to share and change it. By contrast, the GNU General Public > Licenses are intended to guarantee your freedom to share and change > free software--to make sure the software is free for all its users. > > This license, the Lesser General Public License, applies to some > specially designated software packages--typically libraries--of the > Free Software Foundation and other authors who decide to use it. You > can use it too, but we suggest you first think carefully about whether > this license or the ordinary General Public License is the better > strategy to use in any particular case, based on the explanations below. > > When we speak of free software, we are referring to freedom of use, > not price. Our General Public Licenses are designed to make sure that > you have the freedom to distribute copies of free software (and charge > for this service if you wish); that you receive source code or can get > it if you want it; that you can change the software and use pieces of > it in new free programs; and that you are informed that you can do > these things. > > To protect your rights, we need to make restrictions that forbid > distributors to deny you these rights or to ask you to surrender these > rights. These restrictions translate to certain responsibilities for > you if you distribute copies of the library or if you modify it. > > For example, if you distribute copies of the library, whether gratis > or for a fee, you must give the recipients all the rights that we gave > you. You must make sure that they, too, receive or can get the source > code. If you link other code with the library, you must provide > complete object files to the recipients, so that they can relink them > with the library after making changes to the library and recompiling > it. And you must show them these terms so they know their rights. > > We protect your rights with a two-step method: (1) we copyright the > library, and (2) we offer you this license, which gives you legal > permission to copy, distribute and/or modify the library. > > To protect each distributor, we want to make it very clear that > there is no warranty for the free library. Also, if the library is > modified by someone else and passed on, the recipients should know > that what they have is not the original version, so that the original > author's reputation will not be affected by problems that might be > introduced by others. > > Finally, software patents pose a constant threat to the existence of > any free program. We wish to make sure that a company cannot > effectively restrict the users of a free program by obtaining a > restrictive license from a patent holder. Therefore, we insist that > any patent license obtained for a version of the library must be > consistent with the full freedom of use specified in this license. > > Most GNU software, including some libraries, is covered by the > ordinary GNU General Public License. This license, the GNU Lesser > General Public License, applies to certain designated libraries, and > is quite different from the ordinary General Public License. We use > this license for certain libraries in order to permit linking those > libraries into non-free programs. > > When a program is linked with a library, whether statically or using > a shared library, the combination of the two is legally speaking a > combined work, a derivative of the original library. The ordinary > General Public License therefore permits such linking only if the > entire combination fits its criteria of freedom. The Lesser General > Public License permits more lax criteria for linking other code with > the library. > > We call this license the "Lesser" General Public License because it > does Less to protect the user's freedom than the ordinary General > Public License. It also provides other free software developers Less > of an advantage over competing non-free programs. These disadvantages > are the reason we use the ordinary General Public License for many > libraries. However, the Lesser license provides advantages in certain > special circumstances. > > For example, on rare occasions, there may be a special need to > encourage the widest possible use of a certain library, so that it becomes > a de-facto standard. To achieve this, non-free programs must be > allowed to use the library. A more frequent case is that a free > library does the same job as widely used non-free libraries. In this > case, there is little to gain by limiting the free library to free > software only, so we use the Lesser General Public License. > > In other cases, permission to use a particular library in non-free > programs enables a greater number of people to use a large body of > free software. For example, permission to use the GNU C Library in > non-free programs enables many more people to use the whole GNU > operating system, as well as its variant, the GNU/Linux operating > system. > > Although the Lesser General Public License is Less protective of the > users' freedom, it does ensure that the user of a program that is > linked with the Library has the freedom and the wherewithal to run > that program using a modified version of the Library. > > The precise terms and conditions for copying, distribution and > modification follow. Pay close attention to the difference between a > "work based on the library" and a "work that uses the library". The > former contains code derived from the library, whereas the latter must > be combined with the library in order to run. > > GNU LESSER GENERAL PUBLIC LICENSE > TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION > > 0. This License Agreement applies to any software library or other > program which contains a notice placed by the copyright holder or > other authorized party saying it may be distributed under the terms of > this Lesser General Public License (also called "this License"). > Each licensee is addressed as "you". > > A "library" means a collection of software functions and/or data > prepared so as to be conveniently linked with application programs > (which use some of those functions and data) to form executables. > > The "Library", below, refers to any such software library or work > which has been distributed under these terms. A "work based on the > Library" means either the Library or any derivative work under > copyright law: that is to say, a work containing the Library or a > portion of it, either verbatim or with modifications and/or translated > straightforwardly into another language. (Hereinafter, translation is > included without limitation in the term "modification".) > > "Source code" for a work means the preferred form of the work for > making modifications to it. For a library, complete source code means > all the source code for all modules it contains, plus any associated > interface definition files, plus the scripts used to control compilation > and installation of the library. > > Activities other than copying, distribution and modification are not > covered by this License; they are outside its scope. The act of > running a program using the Library is not restricted, and output from > such a program is covered only if its contents constitute a work based > on the Library (independent of the use of the Library in a tool for > writing it). Whether that is true depends on what the Library does > and what the program that uses the Library does. > > 1. You may copy and distribute verbatim copies of the Library's > complete source code as you receive it, in any medium, provided that > you conspicuously and appropriately publish on each copy an > appropriate copyright notice and disclaimer of warranty; keep intact > all the notices that refer to this License and to the absence of any > warranty; and distribute a copy of this License along with the > Library. > > You may charge a fee for the physical act of transferring a copy, > and you may at your option offer warranty protection in exchange for a > fee. > > 2. You may modify your copy or copies of the Library or any portion > of it, thus forming a work based on the Library, and copy and > distribute such modifications or work under the terms of Section 1 > above, provided that you also meet all of these conditions: > > a) The modified work must itself be a software library. > > b) You must cause the files modified to carry prominent notices > stating that you changed the files and the date of any change. > > c) You must cause the whole of the work to be licensed at no > charge to all third parties under the terms of this License. > > d) If a facility in the modified Library refers to a function or a > table of data to be supplied by an application program that uses > the facility, other than as an argument passed when the facility > is invoked, then you must make a good faith effort to ensure that, > in the event an application does not supply such function or > table, the facility still operates, and performs whatever part of > its purpose remains meaningful. > > (For example, a function in a library to compute square roots has > a purpose that is entirely well-defined independent of the > application. Therefore, Subsection 2d requires that any > application-supplied function or table used by this function must > be optional: if the application does not supply it, the square > root function must still compute square roots.) > > These requirements apply to the modified work as a whole. If > identifiable sections of that work are not derived from the Library, > and can be reasonably considered independent and separate works in > themselves, then this License, and its terms, do not apply to those > sections when you distribute them as separate works. But when you > distribute the same sections as part of a whole which is a work based > on the Library, the distribution of the whole must be on the terms of > this License, whose permissions for other licensees extend to the > entire whole, and thus to each and every part regardless of who wrote > it. > > Thus, it is not the intent of this section to claim rights or contest > your rights to work written entirely by you; rather, the intent is to > exercise the right to control the distribution of derivative or > collective works based on the Library. > > In addition, mere aggregation of another work not based on the Library > with the Library (or with a work based on the Library) on a volume of > a storage or distribution medium does not bring the other work under > the scope of this License. > > 3. You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. To do > this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version 2, > instead of to this License. (If a newer version than version 2 of the > ordinary GNU General Public License has appeared, then you can specify > that version instead if you wish.) Do not make any other change in > these notices. > > Once this change is made in a given copy, it is irreversible for > that copy, so the ordinary GNU General Public License applies to all > subsequent copies and derivative works made from that copy. > > This option is useful when you wish to copy part of the code of > the Library into a program that is not a library. > > 4. You may copy and distribute the Library (or a portion or > derivative of it, under Section 2) in object code or executable form > under the terms of Sections 1 and 2 above provided that you accompany > it with the complete corresponding machine-readable source code, which > must be distributed under the terms of Sections 1 and 2 above on a > medium customarily used for software interchange. > > If distribution of object code is made by offering access to copy > from a designated place, then offering equivalent access to copy the > source code from the same place satisfies the requirement to > distribute the source code, even though third parties are not > compelled to copy the source along with the object code. > > 5. A program that contains no derivative of any portion of the > Library, but is designed to work with the Library by being compiled or > linked with it, is called a "work that uses the Library". Such a > work, in isolation, is not a derivative work of the Library, and > therefore falls outside the scope of this License. > > However, linking a "work that uses the Library" with the Library > creates an executable that is a derivative of the Library (because it > contains portions of the Library), rather than a "work that uses the > library". The executable is therefore covered by this License. > Section 6 states terms for distribution of such executables. > > When a "work that uses the Library" uses material from a header file > that is part of the Library, the object code for the work may be a > derivative work of the Library even though the source code is not. > Whether this is true is especially significant if the work can be > linked without the Library, or if the work is itself a library. The > threshold for this to be true is not precisely defined by law. > > If such an object file uses only numerical parameters, data > structure layouts and accessors, and small macros and small inline > functions (ten lines or less in length), then the use of the object > file is unrestricted, regardless of whether it is legally a derivative > work. (Executables containing this object code plus portions of the > Library will still fall under Section 6.) > > Otherwise, if the work is a derivative of the Library, you may > distribute the object code for the work under the terms of Section 6. > Any executables containing that work also fall under Section 6, > whether or not they are linked directly with the Library itself. > > 6. As an exception to the Sections above, you may also combine or > link a "work that uses the Library" with the Library to produce a > work containing portions of the Library, and distribute that work > under terms of your choice, provided that the terms permit > modification of the work for the customer's own use and reverse > engineering for debugging such modifications. > > You must give prominent notice with each copy of the work that the > Library is used in it and that the Library and its use are covered by > this License. You must supply a copy of this License. If the work > during execution displays copyright notices, you must include the > copyright notice for the Library among them, as well as a reference > directing the user to the copy of this License. Also, you must do one > of these things: > > a) Accompany the work with the complete corresponding > machine-readable source code for the Library including whatever > changes were used in the work (which must be distributed under > Sections 1 and 2 above); and, if the work is an executable linked > with the Library, with the complete machine-readable "work that > uses the Library", as object code and/or source code, so that the > user can modify the Library and then relink to produce a modified > executable containing the modified Library. (It is understood > that the user who changes the contents of definitions files in the > Library will not necessarily be able to recompile the application > to use the modified definitions.) > > b) Use a suitable shared library mechanism for linking with the > Library. A suitable mechanism is one that (1) uses at run time a > copy of the library already present on the user's computer system, > rather than copying library functions into the executable, and (2) > will operate properly with a modified version of the library, if > the user installs one, as long as the modified version is > interface-compatible with the version that the work was made with. > > c) Accompany the work with a written offer, valid for at > least three years, to give the same user the materials > specified in Subsection 6a, above, for a charge no more > than the cost of performing this distribution. > > d) If distribution of the work is made by offering access to copy > from a designated place, offer equivalent access to copy the above > specified materials from the same place. > > e) Verify that the user has already received a copy of these > materials or that you have already sent this user a copy. > > For an executable, the required form of the "work that uses the > Library" must include any data and utility programs needed for > reproducing the executable from it. However, as a special exception, > the materials to be distributed need not include anything that is > normally distributed (in either source or binary form) with the major > components (compiler, kernel, and so on) of the operating system on > which the executable runs, unless that component itself accompanies > the executable. > > It may happen that this requirement contradicts the license > restrictions of other proprietary libraries that do not normally > accompany the operating system. Such a contradiction means you cannot > use both them and the Library together in an executable that you > distribute. > > 7. You may place library facilities that are a work based on the > Library side-by-side in a single library together with other library > facilities not covered by this License, and distribute such a combined > library, provided that the separate distribution of the work based on > the Library and of the other library facilities is otherwise > permitted, and provided that you do these two things: > > a) Accompany the combined library with a copy of the same work > based on the Library, uncombined with any other library > facilities. This must be distributed under the terms of the > Sections above. > > b) Give prominent notice with the combined library of the fact > that part of it is a work based on the Library, and explaining > where to find the accompanying uncombined form of the same work. > > 8. You may not copy, modify, sublicense, link with, or distribute > the Library except as expressly provided under this License. Any > attempt otherwise to copy, modify, sublicense, link with, or > distribute the Library is void, and will automatically terminate your > rights under this License. However, parties who have received copies, > or rights, from you under this License will not have their licenses > terminated so long as such parties remain in full compliance. > > 9. You are not required to accept this License, since you have not > signed it. However, nothing else grants you permission to modify or > distribute the Library or its derivative works. These actions are > prohibited by law if you do not accept this License. Therefore, by > modifying or distributing the Library (or any work based on the > Library), you indicate your acceptance of this License to do so, and > all its terms and conditions for copying, distributing or modifying > the Library or works based on it. > > 10. Each time you redistribute the Library (or any work based on the > Library), the recipient automatically receives a license from the > original licensor to copy, distribute, link with or modify the Library > subject to these terms and conditions. You may not impose any further > restrictions on the recipients' exercise of the rights granted herein. > You are not responsible for enforcing compliance by third parties with > this License. > > 11. If, as a consequence of a court judgment or allegation of patent > infringement or for any other reason (not limited to patent issues), > conditions are imposed on you (whether by court order, agreement or > otherwise) that contradict the conditions of this License, they do not > excuse you from the conditions of this License. If you cannot > distribute so as to satisfy simultaneously your obligations under this > License and any other pertinent obligations, then as a consequence you > may not distribute the Library at all. For example, if a patent > license would not permit royalty-free redistribution of the Library by > all those who receive copies directly or indirectly through you, then > the only way you could satisfy both it and this License would be to > refrain entirely from distribution of the Library. > > If any portion of this section is held invalid or unenforceable under any > particular circumstance, the balance of the section is intended to apply, > and the section as a whole is intended to apply in other circumstances. > > It is not the purpose of this section to induce you to infringe any > patents or other property right claims or to contest validity of any > such claims; this section has the sole purpose of protecting the > integrity of the free software distribution system which is > implemented by public license practices. Many people have made > generous contributions to the wide range of software distributed > through that system in reliance on consistent application of that > system; it is up to the author/donor to decide if he or she is willing > to distribute software through any other system and a licensee cannot > impose that choice. > > This section is intended to make thoroughly clear what is believed to > be a consequence of the rest of this License. > > 12. If the distribution and/or use of the Library is restricted in > certain countries either by patents or by copyrighted interfaces, the > original copyright holder who places the Library under this License may add > an explicit geographical distribution limitation excluding those countries, > so that distribution is permitted only in or among countries not thus > excluded. In such case, this License incorporates the limitation as if > written in the body of this License. > > 13. The Free Software Foundation may publish revised and/or new > versions of the Lesser General Public License from time to time. > Such new versions will be similar in spirit to the present version, > but may differ in detail to address new problems or concerns. > > Each version is given a distinguishing version number. If the Library > specifies a version number of this License which applies to it and > "any later version", you have the option of following the terms and > conditions either of that version or of any later version published by > the Free Software Foundation. If the Library does not specify a > license version number, you may choose any version ever published by > the Free Software Foundation. > > 14. If you wish to incorporate parts of the Library into other free > programs whose distribution conditions are incompatible with these, > write to the author to ask for permission. For software which is > copyrighted by the Free Software Foundation, write to the Free > Software Foundation; we sometimes make exceptions for this. Our > decision will be guided by the two goals of preserving the free status > of all derivatives of our free software and of promoting the sharing > and reuse of software generally. > > NO WARRANTY > > 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO > WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. > EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR > OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY > KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE > IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE > LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME > THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. > > 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN > WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY > AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU > FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR > CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE > LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING > RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A > FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF > SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH > DAMAGES. > > END OF TERMS AND CONDITIONS > > How to Apply These Terms to Your New Libraries > > If you develop a new library, and you want it to be of the greatest > possible use to the public, we recommend making it free software that > everyone can redistribute and change. You can do so by permitting > redistribution under these terms (or, alternatively, under the terms of the > ordinary General Public License). > > To apply these terms, attach the following notices to the library. It is > safest to attach them to the start of each source file to most effectively > convey the exclusion of warranty; and each file should have at least the > "copyright" line and a pointer to where the full notice is found. > > > Copyright (C) > > This library is free software; you can redistribute it and/or > modify it under the terms of the GNU Lesser General Public > License as published by the Free Software Foundation; either > version 2.1 of the License, or (at your option) any later version. > > This library is distributed in the hope that it will be useful, > but WITHOUT ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > Lesser General Public License for more details. > > You should have received a copy of the GNU Lesser General Public > License along with this library; if not, write to the Free Software > Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > > Also add information on how to contact you by electronic and paper mail. > > You should also get your employer (if you work as a programmer) or your > school, if any, to sign a "copyright disclaimer" for the library, if > necessary. Here is a sample; alter the names: > > Yoyodyne, Inc., hereby disclaims all copyright interest in the > library `Frob' (a library for tweaking knobs) written by James Random Hacker. > > , 1 April 1990 > Ty Coon, President of Vice > > That's all there is to it! > ------------------------ end of proposed license ------------------ > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From gjhanna at gmail.com Sun Mar 11 14:21:17 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Mon, 12 Mar 2007 09:21:17 +1300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hi Pavel, We are using RXTX under VMWare server in production, quite satisfactorily. We're using Red Hat Enterprise Server 4, and ... Whatever the "enterprise" VMWare product is. Regards, Greg H > Subject: [Rxtx] RXTX under VMWare server > To: rxtx at qbang.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. [ ... snip ... ] -- Pavel Parkhomenko -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070311/4cebb6f9/attachment-0010.html From gergg at cox.net Sun Mar 11 23:39:19 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 12 Mar 2007 00:39:19 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: <45F4E787.6050502@cox.net> Trent Jarvi wrote: > I can start going through the method interfaces later this week and giving > feedback. I would suggest that the JSR should not be too generic in > nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel > drivers that intend to look like EIA232 ports at the kernel driver level. > > some ideas: > > EIA232PortInterface > TermiosInterface > SerialPortInterface > > Something that differentiates this from thing like USB, I2C, ... which > should not have to deal with legacy serial claiming to be the comm api. I'm going to throw out a suggestion, which I am mostly serious about. What would happen if we took the appropriate bits of the J2ME connector API, and just used that as the new COMM API so that finally JSE and JME had a common foundation for these kinds of things? Gregg Wonderly From ra85551 at gmail.com Mon Mar 12 09:08:37 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Mon, 12 Mar 2007 18:08:37 +0300 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Should any application use the modem, HyperTerminal won't be able to talk to the modem. But it actually can send and receive AT comands, while my application cannot :-( > Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Thansk for the reference. I examined that example and found that there's no significant differences between my read/write implementation and that one, except that SimpleSnuV1 listens for serialEvent's, but not for sake of data retrieval, just for printing them out - I don't know why ;-) > Note that modems could care less what OS is on top. If you are trying to > match new lines to the OS and sending it to the mode for AT commands, > thats probably a mistake. I do send strings to serial port, not to OS, and do try to get answers back. If it is the mistake, what's the right way? > Also it would not hurt to print out the > individual bytes that you are sending to make sure they did not get > mangled along the path. Yeah, I am printing these bytes before doing write, but it means that I only see what I intend to write. How can I ensure that these bytes have gone out of the box and reached my modem? BTW, I found that my send/receive method is complex enough, so I've rewritten it. Please, see the following code and point any mistakes, because I don't know where can they remain yet. private static final int LARGE_TIMEOUT = 15000; private static final int SMALL_TIMEOUT = 500; ... private String sendATCommand(String command, String waitFor, boolean isRegex, boolean isAddCRLF) throws BeaconConnectException { byte[] buffer = new byte[512]; int offset; String result = ""; try { if (waitFor != null) { serialPort.enableReceiveTimeout(LARGE_TIMEOUT); } else { serialPort.enableReceiveTimeout(SMALL_TIMEOUT); } if (command != null) { OutputStream serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } offset = 0; InputStream serialInput = serialPort.getInputStream(); while (serialInput.available() != -1) { int bytesRead = serialInput.read(buffer, offset, buffer.length - offset); if (bytesRead == 0) { break; } offset += bytesRead; result = new String(buffer, 0, offset).trim(); if (waitFor != null) { System.out.println(result); if (isRegex && result.matches(waitFor) || result.contains(waitFor)) { break; } } } } catch (UnsupportedCommOperationException e) { throw new MyException("unsupported operation"); } catch (IOException e) { throw new MytException("serial I/O error"); } return result; } -- Pavel Parkhomenko From clayno at hotpop.com Thu Mar 15 02:47:34 2007 From: clayno at hotpop.com (Christopher Layno) Date: Thu, 15 Mar 2007 16:47:34 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi, we're using the latest release of rxtx (2.1-7r2) for our system that has two applications using the library. one application sends requests to the modem while the other simply checks the modem status. we deployed our system on a pentium machine with red hat linux 9.0 installed. now the problem arises when these two applications try to access the same modem at the same time. one of them will eventually have to throw the PortInUseException as shown below: 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException gnu.io.PortInUseException: root PID = 743 Program = java root PID = 743 Program = java root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) this was expected. what we didn't expect though was that if we repeat the scenario 5 times, always 5 times, the application would also throw a VM error: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4473CD21 Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so Current Java thread: at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) - locked <0x44cfd4c8> (a gnu.io.CommPortIdentifier) at ************ at ************ - locked <0x4476a468> (a **********) at ************ at ************ at ************ at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java :261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages( TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run( TCPTransport.java:701) at java.lang.Thread.run(Thread.java:534) note: i replaced some sensitive data with asterisks our team has looked everywhere on the internet, including your mail archives, for a solution to this problem but to no avail. i really hope you could help us out on this one. thanks in advance! best regards, chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070315/1936460a/attachment-0010.html From tjarvi at qbang.org Fri Mar 16 04:30:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 04:30:25 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: On Thu, 15 Mar 2007, Christopher Layno wrote: > hi, > > we're using the latest release of rxtx (2.1-7r2) for our system that has two > applications using the library. one application sends requests to the modem > while the other simply checks the modem status. we deployed our system on a > pentium machine with red hat linux 9.0 installed. > > now the problem arises when these two applications try to access the same > modem at the same time. one of them will eventually have to throw the > PortInUseException as shown below: > > 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException > gnu.io.PortInUseException: root PID = 743 Program = java root PID = > 743 Program = java root PID = 743 Program = ??? root PID = 743 Program > = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root > PID = 743 Program = ??? root PID = 743 Program = ??? > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > > this was expected. what we didn't expect though was that if we repeat the > scenario 5 times, always 5 times, the application would also throw a VM > error: > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x4473CD21 > Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 > Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so > > Current Java thread: > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) Hi Chris The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. The code is originally by Werner Almesberger. He gave us permission to use it in rxtx. You might look at what has changed since 1998 in his fuser application. Or you can just do like other OSs and do the following in fuserImp.c JNIEXPORT jstring JNICALL Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv *env, jobject obj, jstring arg) { return (*env)->NewStringUTF(env, "Unknown Application"); } It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. -- Trent Jarvi tjarvi at qang.org From Adrien.TOS at ingenico.com Fri Mar 16 05:11:12 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Fri, 16 Mar 2007 12:11:12 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903CBC312@frsnprexc1.usr.ingenico.loc> Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070316/972ab214/attachment-0010.html From joachim at buechse.de Fri Mar 16 05:13:24 2007 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 16 Mar 2007 12:13:24 +0100 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. From tjarvi at qbang.org Fri Mar 16 16:36:29 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 16:36:29 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Fri Mar 16 16:02:23 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 16 Mar 2007 18:02:23 -0400 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Not all platforms are Unix based. Also mixing native library usage and command-line calls is not an elegant solution, IMHO. One or the other, but not both. Andre On 16-Mar-07, at 07:13 , Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is > trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We >> only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From clayno at hotpop.com Sun Mar 18 22:17:28 2007 From: clayno at hotpop.com (Christopher Layno) Date: Mon, 19 Mar 2007 12:17:28 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi everyone, thank you so much for your replies. they were really helpful. anyway, before i sent the email, my team was already implementing a temporary solution by using joachim's suggestion. we invoked a lsof command from our java code although i share the same concern with trent and andre-john about portability issues. that's why i said it's just temporary. my superiors have yet to approve our bug fix. so my question now is this: is recompiling the rxtx source code the only way to solve this problem? because if it's the only solution, then i think my superiors would rather have a new release from the rxtx community itself that fixes this bug(?) rather than have my team recompile the source code. best regards, chris Trent Jarvi wrote: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. ... It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070318/237463b2/attachment-0010.html From tjarvi at qbang.org Mon Mar 19 16:20:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Mar 2007 16:20:52 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: Hi Chris I can compile a new version after the 21st if you do not feel comfortable doing so. Please send me an email reminder off-line then. On Mon, 19 Mar 2007, Christopher Layno wrote: > hi everyone, > > thank you so much for your replies. they were really helpful. > > anyway, before i sent the email, my team was already implementing a > temporary solution by using joachim's suggestion. > we invoked a lsof command from our java code although i share the same > concern with trent and andre-john about > portability issues. that's why i said it's just temporary. my superiors have > yet to approve our bug fix. > > so my question now is this: is recompiling the rxtx source code the only way > to solve this problem? because if it's the only > solution, then i think my superiors would rather have a new release from the > rxtx community itself that fixes this bug(?) > rather than have my team recompile the source code. > > best regards, > > chris > > Trent Jarvi wrote: > > Hi Joachim > > It would be nice to have that functionality but calling the program > introduces too many issues imho. Explaining to someone why rxtx invoked a > rogue lsof does not sound very interesting. > > On Fri, 16 Mar 2007, Joachim Buechse wrote: > > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: > > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. > > _______________________________________________ > Rxtx mailing list > Rxtx 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 Eric.Arseneau at sun.com Tue Mar 20 11:47:33 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Tue, 20 Mar 2007 10:47:33 -0700 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 Message-ID: <46001E35.9040608@sun.com> Anyone have any experience with RXTX working with JDK 6 on other platforms ? From mm at UDel.Edu Tue Mar 20 12:18:29 2007 From: mm at UDel.Edu (Mike Markowski) Date: Tue, 20 Mar 2007 14:18:29 -0400 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 In-Reply-To: <46001E35.9040608@sun.com> References: <46001E35.9040608@sun.com> Message-ID: <46002575.4000306@udel.edu> Eric Arseneau wrote: > Anyone have any experience with RXTX working with JDK 6 on other platforms ? I'm using 32 bit intel, gentoo linux, jdk6 with no problems. My applications only use a serial port, though, nothing on the parallel port. Mike From falko.guderian at gmx.de Wed Mar 21 08:17:35 2007 From: falko.guderian at gmx.de (Falko Guderian) Date: Wed, 21 Mar 2007 15:17:35 +0100 Subject: [Rxtx] RXTX binaries for SH4 Message-ID: <46013E7F.40102@gmx.de> Dear developers, I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no possiblities to compile the source code. Better, I'm not able to do this at the moment. Can you provide me with rxtxSerial.dll (SH4) in the rxtx-2.1-8-testing version? (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) The reason for the testing version is I need custom baud rates. Thanks for help. Kind regards, Falko Guderian From tjarvi at qbang.org Wed Mar 21 21:38:37 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Mar 2007 21:38:37 -0600 (MDT) Subject: [Rxtx] RXTX binaries for SH4 In-Reply-To: <46013E7F.40102@gmx.de> References: <46013E7F.40102@gmx.de> Message-ID: On Wed, 21 Mar 2007, Falko Guderian wrote: > Dear developers, > > I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no > possiblities to compile the source code. Better, I'm not able to do this > at the moment. Can you provide me with rxtxSerial.dll (SH4) in the > rxtx-2.1-8-testing version? > (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) > > The reason for the testing version is I need custom baud rates. > > Thanks for help. > Hi Falko WinCE binary format is not supported by gcc. That makes compiling limited to those familiar with the WinCE tools. I hope someone is able to provide them for you but it is not likely. WinCE has been compiled by others in the past but rxtx.org builds have never included WinCE. There is some information with the source concerning WinCE builds if you decide to do it. We can share your results too if you like. The source in the WinCE has never been updated for the custom baud rate. That would need changes from the main source I presume. If you look at the source, you will note that Michal Hobot created a mini fork in the source to handle wince but it has not been updated for 3 years. -- Trent Jarvi tjarvi at qbang.org From Adrien.TOS at ingenico.com Thu Mar 22 07:08:55 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Thu, 22 Mar 2007 14:08:55 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Hi everybody, Do you have any comments on this issue? Thanks! AT ________________________________ De : Adrien TOS Envoy? : vendredi 16 mars 2007 12:11 ? : 'rxtx at qbang.org' Cc : Adrien TOS Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070322/2306c538/attachment-0010.html From jeremy.reeve at zen.co.uk Mon Mar 19 07:36:04 2007 From: jeremy.reeve at zen.co.uk (Jeremy S. Reeve) Date: Mon, 19 Mar 2007 13:36:04 +0000 Subject: [Rxtx] rxtx failing to compile on Fedora Core 6 Message-ID: <1174311364.21865.6.camel@d9thc> When trying to compile latest source : rxtx-2.1-7r2 I get the following when running configure: ---------------- checking os.version 2.6.18-1.2200.fc5smp WARNING: configure is having a hard time determining which directory contains the file jni_md.h. Edit Makefile and fix the variable JAVANATINC to point to the correct directory. The following options are available: /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/ /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/linux/ If there are more than one option available the first was selected. WARNING: Kernel include files do not match the current kernel configure: creating ./config.status ------------------------ which seems OK checking the resultant Makefile but when attempting to build with gmake install I get the following output : ---------------------- 34 problems (34 warnings)/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/javah -classpath .:/home/jsr/rxtxsrc/rxtx-2.1-7r2:/home/jsr/rxtxsrc/rxtx-2.1-7r2/src:/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/ext/RXTXcomm.jar -d i686-pc-linux-gnu -jni `(for i in CommDriver CommPortEnumerator CommPortIdentifier CommPort CommPortOwnershipListener Configure I2C I2CPortEvent I2CPortEventListener I2CPort LPRPort NoSuchPortException ParallelPortEvent ParallelPortEventListener ParallelPort PortInUseException Raw RawPortEvent RawPortEventListener RawPort RS485 RS485PortEvent RS485PortEventListener RS485Port RXTXCommDriver RXTXPort RXTXVersion SerialPortEvent SerialPortEventListener SerialPort UnsupportedCommOperationException UnSupportedLoggerException Zystem;do \ if grep > /dev/null native.* \( /home/jsr/rxtxsrc/rxtx-2.1-7r2/./src/$i.java; then \ echo gnu.io.$i; \ fi; \ done)` i686-pc-linux-gnu/gnu_io_CommPortIdentifier.h: No such file or directory make: *** [/home/jsr/rxtxsrc/rxtx-2.1-7r2/gnu/io/CommDriver.class] Error 1 ------------------------ Any ideas or pointers? Regards, Jeremy From tjarvi at qbang.org Sat Mar 24 08:12:54 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 Mar 2007 08:12:54 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > From Adrien.TOS at ingenico.com Sat Mar 24 11:53:22 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Sat, 24 Mar 2007 18:53:22 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> I do not have the threshold setting enabled, I have explicitely disabled it with: port_.disableReceiveThreshold(); I have also run the same tests with the threshold setting enabled, but they also fail in the same way as described below. So it seems there is a problem with timeout handling on Win32? ________________________________ From: rxtx-bounces at qbang.org on behalf of Trent Jarvi Sent: Sat 3/24/2007 3:12 PM To: RXTX Developers and Users Subject: Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 8312 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20070324/f9e39c9b/attachment-0010.bin From greg.johnson at manchester.ac.uk Sun Mar 25 13:41:36 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Sun, 25 Mar 2007 21:41:36 +0200 Subject: [Rxtx] Mac intel weirdness Message-ID: Hi folks, I'm trying to get rxtx to work on my macbook pro with a USB-serial dongle on it. I am using the 2.1-8 code from the CVS (though it seems to report itself as 2.1-7: makes it difficult to prove to oneself that the changes have 'taken'! - line 4210 in SerialImp.c, line 40 in RXTXVersion.java) I am trying the 2.1-8 because of horrible lock problems in 2.1-7. However, the serialport closure code seems to be broken - it won't close because it believes the (previously opened!) port doesn't exist. Here is what I'm trying: 0. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "false" 1. Open a port Serialport serialport = (SerialPort) commportidentifier.open ("test",100); 2. Talk to a device ... 3. Close port serialport.close(); 4. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "true" - why is this? 5. Try to reopen port Serialport serialport2 = (SerialPort) commportidentifier.open("test", 100); throws PortInUseException. I've dug around a bit in the source, and it seems the SerialPort.close () should call the CommPortIdentifier.internalClosePort() (line 67 of CommPort.java). However, I crash out with the NoSuchPortException when getPortIdentifier is called. Which seems quite weird to me, seeing as it is called on this - which was create just beforehand. Does anyone know how to fix this? Cheers, greg From knute at frazmtn.com Sat Mar 24 10:32:38 2007 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 24 Mar 2007 09:32:38 -0700 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc>, Message-ID: <4604F036.17833.135298@knute.frazmtn.com> > >The behavior of timeout depends upon the setting of the threshold. Do you >have the threshold setting? > This is the same bug I reported last fall. There was a fellow that sent me an email asking if it had been fixed. I told him I didn't think so. He got somebody to write a fix for him but I have not been able to contact him again for the actual changes. The inaccurate timeout and the failure of blocking when no timeouts are set is a serious bug in my humble opinion and renders the software unusable for my applications. I'd really like to have an alternative to the Sun comm api but there just isn't one that I know of. -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Mar 26 16:17:00 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 26 Mar 2007 16:17:00 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> Message-ID: >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. From ra85551 at gmail.com Tue Mar 27 10:18:36 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Tue, 27 Mar 2007 20:18:36 +0400 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Ultimately I found a solution. At first, that wasn't actually the VMWare + WinXP + RXTX issue, that was WinXP + RXTX issue. But on pure XP it sometimes workes, sometimes not, while under VMWare I had never seen my snippet working at all. SimpleSnuV1.java would not help me, because there is only one line I missed, and SimpleSnuV1.java also doesn't contain it! It is as follows: serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_OUT | SerialPort.FLOWCONTROL_RTSCTS_IN); Thank you for your attention. -- Pavel Parkhomenko From griff at op.pl Wed Mar 28 01:28:19 2007 From: griff at op.pl (griff@op.pl) Date: Wed, 28 Mar 2007 09:28:19 +0200 Subject: [Rxtx] No blocking read on Windows. Message-ID: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/5d07d571/attachment-0010.html -------------- next part -------------- Hi, I have problem that InputStram.read() (SerialPort)?returns -1 instead blocking and waiting for data. I found that this problem was ?known in 2005 : ? >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > >> Hi Trent >> >> Thanks for the fast response. >> Here's a Q&D test program for the blocking read on windows that just >> attempts to read one byte, and prints the resulting byte. On my system it >> returns -1, where I expect that it keeps waiting for data. >> >This isn't happening on Linux so the bug is in src/termios.c.? I'll have >something this weekend to fix that. I'm using RXTX 2.1.7r2 and the problem still is here. Im using Windows XP and java 1.5 disableReciveTimeout() and disableReciveTreshhold() dont help. ? best regards ? Piotr Zielniok From Adrien.TOS at ingenico.com Wed Mar 28 01:40:46 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Wed, 28 Mar 2007 09:40:46 +0200 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903E88880@frsnprexc1.usr.ingenico.loc> Looking at the code, it seems there is no support for infinite timeout? And maybe the count++ < 20 condition is breaking out of the loop too early? The only condition to break out of the loop should either be the timeout has expired or the number of requested bytes has been received. -----Message d'origine----- De : rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] De la part de Trent Jarvi Envoy? : mardi 27 mars 2007 00:17 ? : RXTX Developers and Users Objet : Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From j.kenneth.gentle at acm.org Wed Mar 28 06:44:15 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 28 Mar 2007 08:44:15 -0400 Subject: [Rxtx] No blocking read on Windows. In-Reply-To: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> References: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> Message-ID: <200703281844.l2SIiITW028614@qbang.org> Just another "ME TOO!" - I'm seeing this problem on Windows XP, jre for windows XP/Embedded. I cranked receiveTimeout up to Integer.MAX_INT, but it doesn't seem to wait that long At 03:28 2007-03-28, you wrote: >Hi, >I have problem that InputStram.read() (SerialPort) returns -1 >instead blocking and waiting for data. I found that this problem >was known in 2005 : > > >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > > > >> Hi Trent > >> > >> Thanks for the fast response. > >> Here's a Q&D test program for the blocking read on windows that just > >> attempts to read one byte, and prints the resulting byte. On my system it > >> returns -1, where I expect that it keeps waiting for data. > >> > > >This isn't happening on Linux so the bug is in src/termios.c. I'll have > >something this weekend to fix that. > >I'm using RXTX 2.1.7r2 and the problem still is here. >Im using Windows XP and java 1.5 >disableReciveTimeout() and disableReciveTreshhold() dont help. > >best regards > >Piotr Zielniok > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From greg.johnson at manchester.ac.uk Wed Mar 28 14:43:29 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Wed, 28 Mar 2007 22:43:29 +0200 Subject: [Rxtx] Cannot close and reopen serial port Message-ID: <377F9765-7A9D-4CE9-9176-FFB63A2594F0@manchester.ac.uk> Dear all, It appears I cannot close a port properly: SerialPort serialport = portid.open("myprog",100); // do some stuff, all works fine serialport.close(); // all seems fine but... SerialPort sp2 = portid.open("myprog",100); throws PortInUseException. And when I dig into the rxtx code, I find in CommPort.java, in close(): CommPortIdentifier cp = CommPortIdentifier.getPortIdentifier(this); (line 64 or there abouts) but this throws a NoSuchPortException which is caught but ignored (line 74ish). Can anyone suggest how this could happen: a port that was valid, opened, and used, throws a NSPE when it comes to closing it? I'm pulling my (remaining) hair out over this one! Cheers, greg PS And thanks for RXTX - it's great to have! PPS (21.-7. winxp/osx both, java 1.5) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/c28852fc/attachment-0010.html From rxtx at vrijheidslaan.net Fri Mar 30 16:52:50 2007 From: rxtx at vrijheidslaan.net (Rob) Date: Fri, 30 Mar 2007 22:52:50 -0000 Subject: [Rxtx] Cvs Question Message-ID: <61896.80.126.150.87.1175295162.squirrel@webmail.provalue.nl> Hi There, Im trying to get the latest version to work on mac osx. Problem is that i can't checkout version 2.1.8. Probably my fault but can some one please give me the alternative commands for: [user at myhost]$ export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot [user at myhost]$ cvs login Thanx, Rob From ra85551 at gmail.com Thu Mar 1 03:47:06 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Thu, 1 Mar 2007 13:47:06 +0300 Subject: [Rxtx] enableReceiveTimeout() issue Message-ID: Hello, world! I found a limitation of 16300 ms for CommPort's enableReceiveTimeout() method, while in original javax.comm docs there are no any references to that. Is that a bug or feature? I actually need longer timeouts sometimees. -- Pavel Parkhomenko From lyon at docjava.com Thu Mar 1 07:54:17 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 01 Mar 2007 09:54:17 -0500 Subject: [Rxtx] parametric singleton design pattern In-Reply-To: References: <22d55aea0702081207q5e7f6785l352d498d6f5f9fb1@mail.gmail.com> <22d55aea0702100034o3bcf42f3j1d1a6257029a67b0@mail.gmail.com> Message-ID: Hi All, I have been thinking about the use of a design pattern to cache resources that are consumed by processes. Toward that end, I have arrived at a parametric singleton design pattern, which I mentioned on this list some time ago. The idea has been published at: http://www.jot.fm/issues/issue_2007_03/column2 I can't help but think that there should be an API available for dealing with the tracking of serial port usage. Perhaps it is a kind of resource manager called the: SerialPortManager basic prototypes already exist in this vain. See, for example: http://www.ce.rit.edu/research/projects/2005_fall/rt_poolsystem/doc/PoolMon/SerialPortManager.html http://www.eventhelix.com/RealtimeMantra/PatternCatalog/serial_port_design_pattern.htm And others shown by a google search on "SerialPortManager" Cheers! - Doug From Eric.Arseneau at sun.com Thu Mar 1 10:15:03 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:15:03 -0800 Subject: [Rxtx] Any known Java 6 issues with RXTX 2.1-7r2 ? Message-ID: <45E70A17.1060206@sun.com> I just did a test on a recent build of Solaris 11 x86 and it seems that I can connect to my serial device fine when Java 5 is the default, but when Java 6 is the default, no go. Any information ? From Eric.Arseneau at sun.com Thu Mar 1 10:19:58 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:19:58 -0800 Subject: [Rxtx] Mac OS X and missing data Message-ID: <45E70B3E.7040908@sun.com> We have a device which is USB based but presents itself as a serial port to a machine. On my MacBook Pro I can get excellent throughput if I get my device to send data as quickly as possible. On the desktop side, if I do an type of disk IO to log the data I get, I end up with some missing data at some point. I hooked up a USB analyzer and did confirm that all the data is sent as expected to the desktop from the device. I found a work around for this, buffer the data in memory and only write the data out when I've received it all. However, when the same code and same device is attempted on a co-workers MacBook Pro (same hardware specs), I get errors and must slow down dramatically the device side's sending of data. Any ideas/recommendations on what I can do to get rid of this error ? From what I can tell, it seems that RXTX is not able to wake up to the interrupts coming in indicating data is ready, quickly enough, is there anything I can do ? From chinkaiw at hotmail.com Fri Mar 2 00:57:43 2007 From: chinkaiw at hotmail.com (Wang Chinkai) Date: Fri, 02 Mar 2007 07:57:43 +0000 Subject: [Rxtx] dynamic detect rs232 port Message-ID: Hi all I have a question about detecting rs232 port dynamicly. I have to aceess some port and detect rs232 port at the same time. Some usb device simulates rs232 port , and I can not know what the port name it gets until it connects,so I have to detect it dynamic,but I have to access another rs232 device at the same time. I found a problem. If I use CommPortIdentifier.getPortIdentifiers() to get new port list , and the other rs232 access function will not close port correctly. So , How can I solve it . Thanks. _________________________________________________________________ ?? 2GB ???? Windows Live Mail ????????????? http://ideas.live.com/programpage.aspx?versionid=5d21c51a-b161-4314-9b0e-4911fb2b2e6d From eu259473 at tele2.it Fri Mar 2 06:16:40 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 02 Mar 2007 14:16:40 +0100 Subject: [Rxtx] rxtx on HP tru 64 unix Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070302/706c7a70/attachment.html From tjarvi at qbang.org Fri Mar 2 08:39:33 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 08:39:33 -0700 (MST) Subject: [Rxtx] rxtx on HP tru 64 unix In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, "Giuseppe Marchese" wrote: > Hi > > I try to install rxtx on hp tru 64 but make fails, > There are somebody that do the same and work. > > > Sorry for may english! > > Hi Giuseppe Could you provide a log of the failure? script ./configure make # use gnu make exit The information will be in the typescript created. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 2 19:56:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 19:56:52 -0700 (MST) Subject: [Rxtx] dynamic detect rs232 port In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, Wang Chinkai wrote: > Hi all > > I have a question about detecting rs232 port dynamicly. > > I have to aceess some port and detect rs232 port at the same time. > Some usb device simulates rs232 port , and I can not know > what the port name it gets until it connects,so I have to detect it > dynamic,but I have to access > another rs232 device at the same time. > > I found a problem. Hi Wang This is a known problem. The code is braindead there. In fact there needs to be events even in a rudamentary way when you add a usb dongle. I'm burried in tasks not far from rxtx but not in rxtx. I can't get to the problem but we would accept patches if you dig into it. [I'm getting to the license question earlier too; I don't have another 10%] -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Fri Mar 2 23:19:01 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 01:19:01 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Hi, Under ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable USB -> serial converter(using virtual com port drivers), with using example code pretty much straight out of http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port opens fine, enumerations all work, etc. My application calls for a large amount of data to be transferred in a short amount of time at 2,000,000 baud. My hardware sends approximately 15,232 bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL converter work fine, and the application works using C++. In C++, I do a hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); to open the port, and a boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); to read the port. The variable buffer fills with the 15238 bytes, and returns. If I do a resultz = is.read(cbuf,0,15238); in java with RXTX where is = new BufferedReader(new InputStreamReader(port.getInputStream())); and where resultz is an int, and cbuf is a char [] cbuf, resultz gets EXACTLY 3968 bytes the first time called. If I call it multiple times, I get roughly 11k total(less than what is sent), never more than the 3968 bytes per is.read() call. My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 bytes. I've played with inputbuffersize, receive threshold, receivetimeout, and so on. The FTDI virtual com port drivers that I'm using are rock solid, and have had zero problems with them using a variety of applications, some of my own, some professionally written, etc. No flow control is used anyplace, no RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. No exceptions are being thrown. What am I doing wrong, and what I can adjust to receive the full 15k bytes in one single read? Thanks! Keith From Eric.Arseneau at sun.com Fri Mar 2 23:32:07 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Fri, 02 Mar 2007 22:32:07 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <45E91667.20501@sun.com> This is the same type of thing that is happening to me on Mac OS X and does not seem to behave the same on different machines. I posted a day or two ago on this with subject "Mac OS X and missing data". Would love to hear if there is a solution to this :) From tjarvi at qbang.org Sat Mar 3 10:54:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 10:54:17 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > Hi, > > Under > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable > USB -> serial converter(using virtual com port drivers), with using example > code pretty much straight out of > http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port > opens fine, enumerations all work, etc. > > My application calls for a large amount of data to be transferred in a short > amount of time at 2,000,000 baud. My hardware sends approximately 15,232 > bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL > converter work fine, and the application works using C++. > > In C++, I do a > > hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, > OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); > > to open the port, and a > > boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); > > to read the port. > > The variable buffer fills with the 15238 bytes, and returns. > > If I do a > > resultz = is.read(cbuf,0,15238); in java with RXTX > > where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > > and where resultz is an int, and cbuf is a char [] cbuf, resultz gets > EXACTLY 3968 bytes the first time called. If I call it multiple times, I get > roughly 11k total(less than what is sent), never more than the 3968 bytes > per is.read() call. > > My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 > bytes. > > I've played with inputbuffersize, receive threshold, receivetimeout, and so > on. The FTDI virtual com port drivers that I'm using are rock solid, and > have had zero problems with them using a variety of applications, some of my > own, some professionally written, etc. No flow control is used anyplace, no > RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. > > No exceptions are being thrown. > > What am I doing wrong, and what I can adjust to receive the full 15k bytes > in one single read? > > Thanks! > Hi Keith I would expect a 20 meg application is going to have different behavior with the OS than a smaller application with respect to the kernel memory managment, schedualing, ... Something subtle could be causing problems. With respect to the recieve timeout and threshold, if you set the timeout to zero and the threshold to the size of data you expect, read should not return until it get that data. You may try with a stand alone application that tests just that with the C/C++ API. If the read is returning with less data when tested for short reads, you have found a bug in the device driver more than likely. The USB dongle vendor would probably be interested in knowing about this. As mentioned, these devices are getting very good; almost bug free. I suspect you found a bug though if you did use the threshold and timeout properly. The missing data is typical when not using flow control. When the OS buffering fills, the hardware will start dropping bytes. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:38:52 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:38:52 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> update: I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now instead of 3968. This makes sense. 128 bytes of overhead + 3968 bytes of data = 4096 transfer size 32 bytes of overhead + 992 bytes of data = 1024 transfer size. 1/4 the data = 1/4 the overhead. I rearranged my reading like so: resultz = is.read(cbuf,0,3968); resultz = is.read(cbuf,3968,3968); resultz = is.read(cbuf,7936,3968); while (!(is.ready())); // wait for ready resultz = is.read(cbuf,11904,3334); and this grabs 15,238 bytes total. BUT, I still have the quandry of the screwed up multi-bytes. I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. Approx 8% of the data. The bad bytes always seem to take the flavor of 0x2018, 0x2019, x2022, x2030, x201d. Are these maybe errors and I don't know what they enumerate to? I still can't believe some other layer isn't handling putting those bytes together all in one stream for me. Thanks Keith ----- Original Message ----- From: "Keith" To: "Bob Jacobsen" ; "RXTX Developers and Users" Sent: Saturday, March 03, 2007 11:26 AM Subject: Re: [Rxtx] is.read() only returning 3968 bytes > Bob, > > > Interesting numerical coincidence is that (max USB transfer) - (what > > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > > needed to transfer that much data. > > I was thinking along the same lines. I don't know USB well, but I do know > that those numbers were close enough to warrant investigating the > relationship between them. > > > I think what you're seeing is the internal buffering of the USB data > > stream. You'll need some form of higher-level buffering to smooth > > that out. > > Shouldn't the InputStreamReader() and BufferedReader() provide this type of > buffering? Isn't that the idea behind those? > > > All hypotheses need to be tested. In this case, a test would be to > > check for missing data. If this idea is right, you'll get _all_ the > > data, but you won't be missing characters. > > I did start looking at the data. -- I'm getting weird results. > > I tried this: > > loopzz = 0; > > for (looptwo = 0; looptwo < 100000; looptwo++) { > while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > > }} > > So I'm reading one character at a time. The good news is that loopzz is > exactly 15238 at the end of the routine, which is perfectly correct. I > picked looptwo value out of thin air. > > The weird results come in terms of the values, the data isn't correct at > least in one case. Look here: > > 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > > This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). > But the 0x89 was replaced by 0x2030. Why the heck would the returned value > be 0x2030?? Why is the returned byte completely out of range? Why the > multibyte return? > > From InputStream in the API: > > read > public abstract int read() > throws IOExceptionReads the next byte of data from the > input stream. The value byte is returned as an int in the range 0 to 255. If > no byte is available because the end of the stream has been reached, the > value -1 is returned. This method blocks until input data is available, the > end of the stream is detected, or an exception is thrown. > Value should be 0-255. > > > In my application time is really critical, reading 1 byte at a time is > probably not going to work. > > Thanks Eric & Bob for looking at this. > > Keith > From tjarvi at qbang.org Sat Mar 3 12:52:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 12:52:27 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > update: > > I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now > instead of 3968. > > This makes sense. > > 128 bytes of overhead + 3968 bytes of data = 4096 transfer size > 32 bytes of overhead + 992 bytes of data = 1024 transfer size. > > 1/4 the data = 1/4 the overhead. > > I rearranged my reading like so: > > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. > Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? > > I still can't believe some other layer isn't handling putting those bytes > together all in one stream for me. > The layer for this in Serial land is flow control. Software and hardware flow control prevent the overruns you observe. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:54:41 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:54:41 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <001a01c75dcd$c8802a70$6600a8c0@jbh757ktruws7g> Trent, Thanks for taking the time to reply. > I would expect a 20 meg application is going to have different behavior > with the OS than a smaller application with respect to the kernel memory > managment, schedualing, ... Something subtle could be causing problems. Well, at least I know the VCP drivers, the OS, etc can handle 2mbps reliably. Without hiccuping or dropping bytes. The C++ code works reliably without flow control. > The missing data is typical when not using flow control. When the OS > buffering fills, the hardware will start dropping bytes. I'm actually not getting MISSING data, I'm getting CORRUPTED data. If you look at my most recent post, I'm getting these bad bytes in place of the correct values: 0x2018, 0x2019, x2022, x2030, x201d. Why would is.read() return values not in the range of 0-255 ? Thanks. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 08:59:14 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 07:59:14 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: At 1:19 AM -0500 3/3/07, Keith wrote: >If I do a > >resultz = is.read(cbuf,0,15238); in java with RXTX > >where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > >and where resultz is an int, and cbuf is a char [] cbuf, resultz gets >EXACTLY 3968 bytes the first time called. If I call it multiple times, I get >roughly 11k total(less than what is sent), never more than the 3968 bytes >per is.read() call. > >My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 >bytes. Interesting numerical coincidence is that (max USB transfer) - (what you get) = 4096-3968 = 128 bytes is (almost) the size of the headers needed to transfer that much data. I think what you're seeing is the internal buffering of the USB data stream. You'll need some form of higher-level buffering to smooth that out. All hypotheses need to be tested. In this case, a test would be to check for missing data. If this idea is right, you'll get _all_ the data, but you won't be missing characters. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 09:26:14 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 11:26:14 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Bob, > Interesting numerical coincidence is that (max USB transfer) - (what > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > needed to transfer that much data. I was thinking along the same lines. I don't know USB well, but I do know that those numbers were close enough to warrant investigating the relationship between them. > I think what you're seeing is the internal buffering of the USB data > stream. You'll need some form of higher-level buffering to smooth > that out. Shouldn't the InputStreamReader() and BufferedReader() provide this type of buffering? Isn't that the idea behind those? > All hypotheses need to be tested. In this case, a test would be to > check for missing data. If this idea is right, you'll get _all_ the > data, but you won't be missing characters. I did start looking at the data. -- I'm getting weird results. I tried this: loopzz = 0; for (looptwo = 0; looptwo < 100000; looptwo++) { while (is.ready()) { cbuf[loopzz] = (char) is.read(); loopzz++; }} So I'm reading one character at a time. The good news is that loopzz is exactly 15238 at the end of the routine, which is perfectly correct. I picked looptwo value out of thin air. The weird results come in terms of the values, the data isn't correct at least in one case. Look here: 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). But the 0x89 was replaced by 0x2030. Why the heck would the returned value be 0x2030?? Why is the returned byte completely out of range? Why the multibyte return? >From InputStream in the API: read public abstract int read() throws IOExceptionReads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown. Value should be 0-255. In my application time is really critical, reading 1 byte at a time is probably not going to work. Thanks Eric & Bob for looking at this. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 14:44:50 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 13:44:50 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: Java's "char" type is Unicode. I think what you're seeing is a bug in the byte -> Unicode translation. 0x2018, 0x2019 are the curly open and close quotes. There used to be (and might still be) bugs in the conversion of these in a couple of libc versions. Some of the ASCII -> ISO and ISO -> ASCII routines were a little over-ambitious with respect to handling the open and close quotes, and tried to convert them to the "curly" form inappropriately. Try _not_ casting it to char. Bob At 11:26 AM -0500 3/3/07, Keith wrote: >Bob, > >> Interesting numerical coincidence is that (max USB transfer) - (what >> you get) = 4096-3968 = 128 bytes is (almost) the size of the headers >> needed to transfer that much data. > >I was thinking along the same lines. I don't know USB well, but I do know >that those numbers were close enough to warrant investigating the >relationship between them. > >> I think what you're seeing is the internal buffering of the USB data >> stream. You'll need some form of higher-level buffering to smooth >> that out. > >Shouldn't the InputStreamReader() and BufferedReader() provide this type of >buffering? Isn't that the idea behind those? > >> All hypotheses need to be tested. In this case, a test would be to >> check for missing data. If this idea is right, you'll get _all_ the >> data, but you won't be missing characters. > >I did start looking at the data. -- I'm getting weird results. > >I tried this: > >loopzz = 0; > >for (looptwo = 0; looptwo < 100000; looptwo++) { >while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > >}} > >So I'm reading one character at a time. The good news is that loopzz is >exactly 15238 at the end of the routine, which is perfectly correct. I >picked looptwo value out of thin air. > >The weird results come in terms of the values, the data isn't correct at >least in one case. Look here: > >0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > >This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). >But the 0x89 was replaced by 0x2030. Why the heck would the returned value >be 0x2030?? Why is the returned byte completely out of range? Why the >multibyte return? > >>From InputStream in the API: > >read >public abstract int read() > throws IOExceptionReads the next byte of data from the >input stream. The value byte is returned as an int in the range 0 to 255. If >no byte is available because the end of the stream has been reached, the >value -1 is returned. This method blocks until input data is available, the >end of the stream is detected, or an exception is thrown. >Value should be 0-255. > > >In my application time is really critical, reading 1 byte at a time is >probably not going to work. > >Thanks Eric & Bob for looking at this. > >Keith > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 15:10:11 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 17:10:11 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Bob said ..... > Java's "char" type is Unicode. I think what you're seeing is a bug > in the byte -> Unicode translation. Bob -- I think you hit the nail on the head. I was just coming to the same realization here. I knew that something funny was going on because the same bytes always got "corrupted." I'm pretty sure its in the InputStreamReader() functionality where the conversion junk is happening. Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. I don't know if simply changing the cast is going to work. Since the conversion is happening upstream (pun intended), I don't think my cast is doing this. Also I think the compiler forced me to use the cast. I'm still playing around, and I'll report back once I nail it down. Thanks!! Keith From tjarvi at qbang.org Sat Mar 3 15:59:46 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 15:59:46 -0700 (MST) Subject: [Rxtx] Win64 rxtx Testers? Message-ID: I have compiled win64 binaries of rxtx. Are there any users interested in testing them? If so, I'll look into putting them on the web site. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Mar 3 15:35:06 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 14:35:06 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: Because of this and similar problems, JMRI does all it's serial IO using +only+ byte values. It's a but of a pain, as Java wants to go to char and int types a little too aggressively, but it does solve the "uncontrolled conversions" problems. Bob At 5:10 PM -0500 3/3/07, Keith wrote: >Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > >Bob -- I think you hit the nail on the head. > >I was just coming to the same realization here. I knew that something funny >was going on because the same bytes always got "corrupted." > >I'm pretty sure its in the InputStreamReader() functionality where the >conversion junk is happening. > >Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > >I don't know if simply changing the cast is going to work. Since the >conversion is happening upstream (pun intended), I don't think my cast is >doing this. Also I think the compiler forced me to use the cast. -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mark at mdsh.com Sun Mar 4 11:01:33 2007 From: mark at mdsh.com (Mark Himsley) Date: Sun, 04 Mar 2007 18:01:33 +0000 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: <5C01AC72C200388815C04982@bedroom.mdsh.local> On 03 March 2007 14:38 -0500 Keith wrote: > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT > consistent. Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? It looks like you need to use DataInputStream and DataOutputStream. -- Mark Himsley From tjarvi at qbang.org Sun Mar 4 11:35:08 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 11:35:08 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" > > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > > * Line #21 - Not sure if you need a (TM) mark for > the term "Sun" > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > OK. I'm going through this today. Some groups ask if rxtx could be under their license also. I think this is a good example of why I resist multiple licenses and focus on why the current license may not be usable by them. The RXTX project is a convergence of hobby and commercial interests. I happen to do both right now. The problem with licensing is we have to stay on top of them as they change. Clearly, adding more licenses will not make this easier. I'm acting as the hobby person today. RXTX always favors the hobby people. But as we move forward, I'm going to need to bring this to lawyers at work and explain to them what is going on. Others here may have to do this also. I don't anticipate problems or unexpected changes. The goal is a consistant, comprehendable and usable license as close to what we have now as possible. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 14:52:10 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 14:52:10 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (1/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: I'm breaking this into two parts. I expect the second part will need more attention. Comments first, then the changed material below. On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > Thanks > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. OK. RXTX for consitent use. java should not be capitalized because it does not only mean Sun [TM] Java [TM]. An example of this not meaning Java is when people use RXTX with GCJ. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". There are not any contributors that are in all of RXTX yet but I did update the comment to try to reflect the current situation without making it a nightmare to maintain. I looked to see how the Linux kernel does it as a reference point. > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" The URL can be problematic. I have done so below with a time reference. GNU does not provide version information in their URLS. I picture this being a problem when the version 3 comes out. > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > This will be corrected when the copy is updated to the version linked below. ---------------- begin proposed material involved -------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. ----------------- end proposed material involved -------------------- I'll be looking at the linking issue again next. That should be all that remains other than including the 2.1 version. Let me know if you have problems with anything here. I do not want to dilute the material I post next with these housekeeping tasks. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 16:08:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 16:08:36 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: For those that are wondering what is going on here, this next bit is the meat of the changes. We agreed a long time ago to put this disclaimer in. We did a so so job. It was in rxtx 2.0, not well written, ... So some groups using rxtx that would like to ship rxtx so users don't need to download, install, go to the mail-list to find why it failed, ... Then their legal teams tell them section 5 paragraph 2 is a show stopper. That was never the intent. Now going through what remains... > and might need a (TM) suffix to make Sun happy. Added disclaimer at the ended 'all trademarks belong...' > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. OK. As you can see I was trying to adjust GNU text there for the LGPL. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. used dynamically linked terminology. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". I tried to address this more upfront with an intent statement. Let me know if you have problems with it. I also tried to make it a little more clear what was derived from the GNU solution by moving the link location closer to GNU's suggestion. > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > Thats the intent. Here is the combined fixes. Note that only the material in /*-- --*/ is being touched. The new GPL license is there but unmodified. ------------------------ begin proposed new license ------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. | | An executable that contains no derivative of any portion of RXTX, but | is designed to work with RXTX by being dynamically linked with it, | is considered a "work that uses the Library" subject to the terms and | conditions of the GNU Lesser General Public License. | | The following has been added to the RXTX License to remove | any confusion about linking to RXTX. We want to allow in part what | section 5, paragraph 2 of the LGPL does not permit in the special | case of linking over a controlled interface. The intent is to add a | Java Specification Request or standards body defined interface in the | future as another exception but one is not currently available. | | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface | | As a special exception, the copyright holders of RXTX give you | permission to link RXTX with independent modules that communicate with | RXTX solely through the Sun Microsytems CommAPI interface version 2, | regardless of the license terms of these independent modules, and to copy | and distribute the resulting combined work under terms of your choice, | provided that every copy of the combined work is accompanied by a complete | copy of the source code of RXTX (the version of RXTX used to produce the | combined work), being distributed under the terms of the GNU Lesser General | Public License plus this exception. An independent module is a | module which is not derived from or based on RXTX. | | Note that people who make modified versions of RXTX are not obligated | to grant this special exception for their modified versions; it is | their choice whether to do so. The GNU Lesser General Public License | gives permission to release a modified version without this exception; this | exception also makes it possible to release a modified version which | carries forward this exception. | | You should have received a copy of the GNU Lesser General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA | All trademarks belong to their respective owners. --------------------------------------------------------------------------*/ The original GNU Lesser General Public License Follows. GNU LESSER GENERAL PUBLIC LICENSE Version 2.1, February 1999 Copyright (C) 1991, 1999 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. [This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence the version number 2.1.] Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This license, the Lesser General Public License, applies to some specially designated software packages--typically libraries--of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below. When we speak of free software, we are referring to freedom of use, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish); that you receive source code or can get it if you want it; that you can change the software and use pieces of it in new free programs; and that you are informed that you can do these things. To protect your rights, we need to make restrictions that forbid distributors to deny you these rights or to ask you to surrender these rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library or if you modify it. For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights. We protect your rights with a two-step method: (1) we copyright the library, and (2) we offer you this license, which gives you legal permission to copy, distribute and/or modify the library. To protect each distributor, we want to make it very clear that there is no warranty for the free library. Also, if the library is modified by someone else and passed on, the recipients should know that what they have is not the original version, so that the original author's reputation will not be affected by problems that might be introduced by others. Finally, software patents pose a constant threat to the existence of any free program. We wish to make sure that a company cannot effectively restrict the users of a free program by obtaining a restrictive license from a patent holder. Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license. Most GNU software, including some libraries, is covered by the ordinary GNU General Public License. This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs. When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library. We call this license the "Lesser" General Public License because it does Less to protect the user's freedom than the ordinary General Public License. It also provides other free software developers Less of an advantage over competing non-free programs. These disadvantages are the reason we use the ordinary General Public License for many libraries. However, the Lesser license provides advantages in certain special circumstances. For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License. In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software. For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU operating system, as well as its variant, the GNU/Linux operating system. Although the Lesser General Public License is Less protective of the users' freedom, it does ensure that the user of a program that is linked with the Library has the freedom and the wherewithal to run that program using a modified version of the Library. The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, whereas the latter must be combined with the library in order to run. GNU LESSER GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License Agreement applies to any software library or other program which contains a notice placed by the copyright holder or other authorized party saying it may be distributed under the terms of this Lesser General Public License (also called "this License"). Each licensee is addressed as "you". A "library" means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables. The "Library", below, refers to any such software library or work which has been distributed under these terms. A "work based on the Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term "modification".) "Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library. Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does. 1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) The modified work must itself be a software library. b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change. c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License. d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful. (For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library. In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. 4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange. If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code. 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables. When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law. If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.) Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself. 6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications. You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things: a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.) b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. c) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution. d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place. e) Verify that the user has already received a copy of these materials or that you have already sent this user a copy. For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute. 7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things: a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above. b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work. 8. You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 9. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Library (or any work based on the Library), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Library or works based on it. 10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties with this License. 11. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply, and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 12. If the distribution and/or use of the Library is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Library under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 13. The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation. 14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Libraries If you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the ordinary General Public License). To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Also add information on how to contact you by electronic and paper mail. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the library, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the library `Frob' (a library for tweaking knobs) written by James Random Hacker. , 1 April 1990 Ty Coon, President of Vice That's all there is to it! ------------------------ end of proposed license ------------------ -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sun Mar 4 16:26:04 2007 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 04 Mar 2007 17:26:04 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <45EB558C.3010609@cox.net> Bob Jacobsen wrote: > Because of this and similar problems, JMRI does all it's serial IO > using +only+ byte values. It's a but of a pain, as Java wants to go > to char and int types a little too aggressively, but it does solve > the "uncontrolled conversions" problems. Anytime that you are reading bytes of data that is not printable, unicode text, in Java, you really need to stay away from the Readers. Use input stream only, or you will see unicode valued byte groups converted to unicode "char" values. Gregg Wonderly From joachim at buechse.de Mon Mar 5 04:23:48 2007 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 5 Mar 2007 12:23:48 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> The behaviour is exactly what you asked for in you code. is = new BufferedReader(new InputStreamReader(port.getInputStream())); Readers return Text (ie unicode chars) not bytes. You instantiate the InputStreamReader without saying which charset you want, which means "platform default". As this is on Windows, it will convert Windows characters to equivalent unicode characters. If you want to read bytes, read bytes not Text. Reading bytes is done with InputStream and BufferedInputStream. BTW: The InputStream and Reader methods that read arrays are not guarenteed to fill up the array. You always have to check what you really got, and advance your index accordingly. A typical "read up to 32k" method looks like this: InputStream is= ... // -- determine the max buffer size int len= is.available(); if (len == 0) { len= 32 * 1024; } // -- read all available data byte[] buffer= new byte[len]; int pos= 0; int read; do { read= is.read(buffer, pos, buffer.length - pos); pos= pos + read; } while (read != -1 && pos < buffer.length); Best regards, Joachim --- Joachim B?chse Phone: +41 44 500 2604 Buechse Consulting Hadlaubsteig 2 CH-8006 Z?rich On 03.03.2007, at 23:10, Keith wrote: > Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > > Bob -- I think you hit the nail on the head. > > I was just coming to the same realization here. I knew that > something funny > was going on because the same bytes always got "corrupted." > > I'm pretty sure its in the InputStreamReader() functionality where the > conversion junk is happening. > > Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > > I don't know if simply changing the cast is going to work. Since the > conversion is happening upstream (pun intended), I don't think my > cast is > doing this. Also I think the compiler forced me to use the cast. > > I'm still playing around, and I'll report back once I nail it down. > > Thanks!! > > Keith > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Mon Mar 5 07:25:46 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 05 Mar 2007 08:25:46 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> Message-ID: <45EC286A.8060608@cox.net> Joachim Buechse wrote: > BTW: The InputStream and Reader methods that read arrays are not > guarenteed to fill up the array. You always have to check what you > really got, and advance your index accordingly. A typical "read up to > 32k" method looks like this: > > InputStream is= ... > // -- determine the max buffer size > int len= is.available(); > if (len == 0) { > len= 32 * 1024; > } > // -- read all available data > byte[] buffer= new byte[len]; > int pos= 0; > int read; > do { > read= is.read(buffer, pos, buffer.length - pos); > pos= pos + read; > } while (read != -1 && pos < buffer.length); > My preferred structure is. byte arr[ len ]; int cnt; int off = 0; while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { off += cnt; } This keeps you from adding -1 to pos when the read returns -1. It also skips out when the read is 0 bytes which, is not a described EOF in InputStream java docs, but is a condition I want to be aware of. Gregg Wonderly From joachim at buechse.de Tue Mar 6 02:52:58 2007 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 6 Mar 2007 10:52:58 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <45EC286A.8060608@cox.net> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: The code I copied was from a file resource reader, it shouldn't really be applied to networking/external IO code. Mea culpa. However aborting when you get 0 from read is not always what you want either (you kind of indicated that already). Some unix java implementations will return 0 if the kernel read was aborted with EINTER, which is rarely the point where you want to abort your read - at least not without further checks. A "complete" solution always depends on the events you need to handle and the time the total read could take in reality. In some cases it's worth checking Thread.isInterrupted() in the loop, some code re-loops on 0 but only a limited number of times, some check a total timeout limit, etc... Best regards, Joachim On 05.03.2007, at 15:25, Gregg Wonderly wrote: > My preferred structure is. > > byte arr[ len ]; > int cnt; > int off = 0; > while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { > off += cnt; > } > > This keeps you from adding -1 to pos when the read returns -1. It > also skips > out when the read is 0 bytes which, is not a described EOF in > InputStream java > docs, but is a condition I want to be aware of. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Mar 6 14:47:44 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 Mar 2007 14:47:44 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: Just FYI, rxtx will usually not break out on EINTER. The code in the native library usually does something close to this: do { read(...) } while ( !done && errno==EINTR ); Obviously there is a little more involved but it will retry on EINTER if not done. On Tue, 6 Mar 2007, Joachim Buechse wrote: > The code I copied was from a file resource reader, it shouldn't > really be applied to networking/external IO code. Mea culpa. > > However aborting when you get 0 from read is not always what you want > either (you kind of indicated that already). Some unix java > implementations will return 0 if the kernel read was aborted with > EINTER, which is rarely the point where you want to abort your read - > at least not without further checks. A "complete" solution always > depends on the events you need to handle and the time the total read > could take in reality. In some cases it's worth checking > Thread.isInterrupted() in the loop, some code re-loops on 0 but only > a limited number of times, some check a total timeout limit, etc... > > Best regards, > Joachim > > On 05.03.2007, at 15:25, Gregg Wonderly wrote: >> My preferred structure is. >> >> byte arr[ len ]; >> int cnt; >> int off = 0; >> while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { >> off += cnt; >> } >> >> This keeps you from adding -1 to pos when the read returns -1. It >> also skips >> out when the read is 0 bytes which, is not a described EOF in >> InputStream java >> docs, but is a condition I want to be aware of. >> >> Gregg Wonderly >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 gjhanna at gmail.com Thu Mar 8 13:42:52 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Fri, 9 Mar 2007 09:42:52 +1300 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? Message-ID: I've just struck an issue using rxtx in a multi-threaded environment: If I have 3 threads trying to open *the same* comm-port I get a deadlock in CommPortIdentifier.open If I have just 2, it works fine - I get a PortInUseException which is nice and I can handle it. The 3 thread->deadlock thing is causing me issues. (Sample code below). This is from the java thread-dump Found one Java-level deadlock: ============================= "Thread-2": waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object ), which is held by "Thread-1" "Thread-1": waiting to lock monitor 0x0003e9cc (object 0x2450e108, a gnu.io.CommPortIdentifier), which is held by "Thread-2" Java stack information for the threads listed above: =================================================== "Thread-2": at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:329) - waiting to lock <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) "Thread-1": at java.lang.Object.wait(Native Method) - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) - locked <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) (Apart from this, rxtx is working fantastically for us). I'm thinking I'll have to implement some sort of locking mechanism that *doesn't* use java synchronization to prevent this situation. (Which doesn't sound like a good idea to me). Any ideas? Thanks, Greg Hanna ============= RXTXLockTest.java ======================================== import gnu.io.CommPort; import gnu.io.CommPortIdentifier; /** * @author Greg Hanna * Minimal code to create a deadlock with rxtx in multithreaded open */ public class RXTXLockTest { public static void main(String[] args) { try { CommPortIdentifier cpiCom1 = CommPortIdentifier.getPortIdentifier ("COM14"); OpenThread t1 = new OpenThread (" one ", cpiCom1); OpenThread t2 = new OpenThread (" two ", cpiCom1); OpenThread t3 = new OpenThread (" 003 ", cpiCom1); t1.start(); t2.start(); t3.start(); // comment this out and it runs with (expected) PortInUseException } catch (Exception e) { e.printStackTrace(); } } } class OpenThread extends Thread { String name; CommPortIdentifier cpi; CommPort cp; public OpenThread (String name, CommPortIdentifier cpi) { this.name = name; this.cpi = cpi; System.out.println (System.currentTimeMillis() + name + " thread created"); } public void run () { try { System.out.println (System.currentTimeMillis() + name + " opening"); cp = cpi.open(name, 2000); System.out.println (System.currentTimeMillis() + name + " opened - sleeping"); sleep (2000); // do the serial comms with the device. System.out.println (System.currentTimeMillis() + name + " slept - closing"); cp.close(); System.out.println (System.currentTimeMillis() + name + " closed - exiting"); } catch (Exception e) { System.out.println ("Error in thread: " + name ); e.printStackTrace(); } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070308/d9a163c5/attachment.html From eu259473 at tele2.it Fri Mar 9 02:46:20 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 09 Mar 2007 10:46:20 +0100 Subject: [Rxtx] rxtx: tru64 unix make fails Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070309/3b654523/attachment.html From lyon at docjava.com Fri Mar 9 03:58:32 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 Mar 2007 05:58:32 -0500 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi All, The deadlock issue is one that I have been thinking about for some time now. It seems to me that we need a resource manager that enables assignment to a known process. The one thing that seems important about serial ports is that two applications should not use the same serial port at the same time. When this happens, it throws an exception. OK. The exception is a response to a lock condition that arises from an unavailable resource. An abstract implementation (not born of native methods) might assign a serial port to an application, until the application releases it (or is forced to release it by some kill mechanism). Some resources (like a registry) can be reused. But others, like the serial port, cannot. In the case of the serial port, we would like, I think, to have the flyweight design pattern without sharing and with object assignment tracking. A means of breaking deadlock (like a leasing mechanism) seems very useful, to me. My guess is that we can serialize the state of the Parametric Singleton Pattern (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) into the Preferences of the System. Preferences.systemRoot() might help with that. When a resource is checked out, the lease time and owner are listed. A thread that does this can be killed, but applications outside of Java are problematic. There is a compelling problem here. It is not just serial ports. Sound cards, cameras, microphones, files, tape drives, etc. All are consumed resources that are assigned to an application (or user) and deprive other applications, or users, from use. What, if anything, should we do? At present we throw PortInUseExceptions. Is that it? Can we do better? OK, the port is in use. Now what? Do I have to be root to go remove lock files and kill applications? Is there a better way? Thanks! - Doug >I've just struck an issue using rxtx in a multi-threaded environment: > >If I have 3 threads trying to open *the same* >comm-port I get a deadlock in >CommPortIdentifier.open >If I have just 2, it works fine - I get a >PortInUseException which is nice and I can >handle it. > >The 3 thread->deadlock thing is causing me issues. >(Sample code below). > >This is from the java thread-dump > >Found one Java-level deadlock: >============================= >"Thread-2": > waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), > which is held by "Thread-1" >"Thread-1": > waiting to lock monitor 0x0003e9cc (object >0x2450e108, a gnu.io.CommPortIdentifier ), > which is held by "Thread-2" > >Java stack information for the threads listed above: >=================================================== >"Thread-2": > at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) > - waiting to lock <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) >"Thread-1": > at java.lang.Object.wait(Native Method) > - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) > - locked <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) > > >(Apart from this, rxtx is working fantastically for us). > >I'm thinking I'll have to implement some sort of >locking mechanism that *doesn't* use java >synchronization to prevent this situation. >(Which doesn't sound like a good idea to me). > >Any ideas? > >Thanks, > >Greg Hanna > >============= RXTXLockTest.java ======================================== > >import gnu.io.CommPort; >import gnu.io.CommPortIdentifier; > >/** > * @author Greg Hanna > * Minimal code to create a deadlock with rxtx in multithreaded open > */ >public class RXTXLockTest { > ? > ?public static void main(String[] args) { > ?try { > ?CommPortIdentifier cpiCom1 = >CommPortIdentifier.getPortIdentifier ("COM14"); > ?OpenThread t1 = new OpenThread (" one ", cpiCom1); > ?OpenThread t2 = new OpenThread (" two ", cpiCom1); > ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); > ?t1.start(); > ?t2.start(); > ?t3.start(); // comment this out >and it runs with (expected) PortInUseException > ?} catch (Exception e) { > ?e.printStackTrace(); > ?} > ?} >} > >class OpenThread extends Thread { > ?String name; > ?CommPortIdentifier cpi; > ?CommPort cp; > ?public OpenThread (String name, CommPortIdentifier cpi) { > ? this.name = name; > ?this.cpi = cpi; > ?System.out.println >(System.currentTimeMillis() + name + " thread >created"); > ?} > ?public void run () { > ?try { > ?System.out.println >(System.currentTimeMillis() + name + " opening"); > ?cp = cpi.open(name, 2000); > ?System.out.println >(System.currentTimeMillis() + name + " opened - >sleeping"); > ?sleep (2000); // do the serial comms with the device. > ?System.out.println >(System.currentTimeMillis() + name + " slept - >closing"); > ?cp.close(); > ?System.out.println >(System.currentTimeMillis() + name + " closed - >exiting"); > ?} catch (Exception e) { > System.out.println ("Error in thread: " + name ); > ?e.printStackTrace(); > ?} > ?} >} > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Mar 9 06:37:45 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 Mar 2007 06:37:45 -0700 (MST) Subject: [Rxtx] rxtx: tru64 unix make fails In-Reply-To: References: Message-ID: On Fri, 9 Mar 2007, "Giuseppe Marchese" wrote: > Sorry for delay. > ? > This is log for ./configure and make > error. > ? > thanks for attention > ? > Make: '%.java,$(TOP)/$(CLASSDEST)/%.class,$(wildcard $(SPATH)/*.java)': extra chars.? > Stop. > Hi Giuseppe You need to use GNU make with the Makefile. I suspect the tru64 make is not happy with those rules. > configure: exit 0 Looks like configure is fairly happy. From tjarvi at qbang.org Sat Mar 10 07:43:51 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 07:43:51 -0700 (MST) Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi Doug I have very little time to look into this further but what we could do is open up an rxtx 3 devel branch in which a proof of concept could be worked on. It could be the proof of concept for a JSR others including Sun could look at/work on or parts of it could be recycled in a JSR. I'm working very hard on rxtx right now but it does not show. I'm looking at win64, mac intel/ppc, usb bluetooth and usb serial dongles. Some are going to be more tested than others but they are all on the plate. I'll be pushing all the fixes upstream when they are done. So I'm very busy in 2.1 but we could open a new branch. On Fri, 9 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > The deadlock issue is one that I have been thinking about > for some time now. > It seems to me that we need a resource manager that enables assignment > to a known process. > > The one thing that seems important about serial > ports is that two applications should not use the > same serial port at the same time. When this > happens, it throws an exception. > OK. > > The exception is a response to a lock condition that > arises from an unavailable resource. > > An abstract implementation (not born of native methods) might > assign a serial port to an application, until the > application releases it (or is forced to release > it by some kill mechanism). > > Some resources (like a registry) can be reused. > But others, like the serial port, > cannot. > > In the case of the serial port, we would like, I think, to > have the flyweight design pattern > without sharing and with object assignment tracking. > A means of breaking deadlock (like a leasing > mechanism) seems very useful, to me. > > My guess is that we can serialize the state of the Parametric Singleton Pattern > (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) > into the Preferences of the System. Preferences.systemRoot() might help > with that. When a resource is checked out, the lease time and owner are > listed. A thread that does this can be killed, but applications outside of Java > are problematic. > > There is a compelling problem here. It is not just serial ports. > Sound cards, cameras, microphones, files, tape drives, etc. All are consumed > resources that are assigned to an application (or > user) and deprive other applications, > or users, from use. > > What, if anything, should we do? At present we throw PortInUseExceptions. > Is that it? > Can we do better? > OK, the port is in use. Now what? > Do I have to be root to go remove lock files and kill applications? > Is there a better way? > > Thanks! > - Doug > >> I've just struck an issue using rxtx in a multi-threaded environment: >> >> If I have 3 threads trying to open *the same* >> comm-port I get a deadlock in >> CommPortIdentifier.open >> If I have just 2, it works fine - I get a >> PortInUseException which is nice and I can >> handle it. >> >> The 3 thread->deadlock thing is causing me issues. >> (Sample code below). >> >> This is from the java thread-dump >> >> Found one Java-level deadlock: >> ============================= >> "Thread-2": >> waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), >> which is held by "Thread-1" >> "Thread-1": >> waiting to lock monitor 0x0003e9cc (object >> 0x2450e108, a gnu.io.CommPortIdentifier ), >> which is held by "Thread-2" >> >> Java stack information for the threads listed above: >> =================================================== >> "Thread-2": >> at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) >> - waiting to lock <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> "Thread-1": >> at java.lang.Object.wait(Native Method) >> - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) >> - locked <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> >> >> (Apart from this, rxtx is working fantastically for us). >> >> I'm thinking I'll have to implement some sort of >> locking mechanism that *doesn't* use java >> synchronization to prevent this situation. >> (Which doesn't sound like a good idea to me). >> >> Any ideas? >> >> Thanks, >> >> Greg Hanna >> >> ============= RXTXLockTest.java ======================================== >> >> import gnu.io.CommPort; >> import gnu.io.CommPortIdentifier; >> >> /** >> * @author Greg Hanna >> * Minimal code to create a deadlock with rxtx in multithreaded open >> */ >> public class RXTXLockTest { >> ? >> ?public static void main(String[] args) { >> ?try { >> ?CommPortIdentifier cpiCom1 = >> CommPortIdentifier.getPortIdentifier ("COM14"); >> ?OpenThread t1 = new OpenThread (" one ", cpiCom1); >> ?OpenThread t2 = new OpenThread (" two ", cpiCom1); >> ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); >> ?t1.start(); >> ?t2.start(); >> ?t3.start(); // comment this out >> and it runs with (expected) PortInUseException >> ?} catch (Exception e) { >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> class OpenThread extends Thread { >> ?String name; >> ?CommPortIdentifier cpi; >> ?CommPort cp; >> ?public OpenThread (String name, CommPortIdentifier cpi) { >> ? this.name = name; >> ?this.cpi = cpi; >> ?System.out.println >> (System.currentTimeMillis() + name + " thread >> created"); >> ?} >> ?public void run () { >> ?try { >> ?System.out.println >> (System.currentTimeMillis() + name + " opening"); >> ?cp = cpi.open(name, 2000); >> ?System.out.println >> (System.currentTimeMillis() + name + " opened - >> sleeping"); >> ?sleep (2000); // do the serial comms with the device. >> ?System.out.println >> (System.currentTimeMillis() + name + " slept - >> closing"); >> ?cp.close(); >> ?System.out.println >> (System.currentTimeMillis() + name + " closed - >> exiting"); >> ?} catch (Exception e) { >> System.out.println ("Error in thread: " + name ); >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 mm at UDel.Edu Sat Mar 10 14:48:32 2007 From: mm at UDel.Edu (Mike Markowski) Date: Sat, 10 Mar 2007 16:48:32 -0500 Subject: [Rxtx] rxtx and Sun's comm api Message-ID: <45F327B0.2060004@udel.edu> Hi all, I joined the list a few days ago and apologize for what is likely a frequently asked question, though I haven't yet found it anywhere. I learned about rxtx.org through the readme on Sun's version 2 of their comms api. They give recommendations in that readme regarding how a better comms api should be written. Is this the aim of rxtx.org? I wrote an app on my linux box using the Sun comms api (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the fact that only linux and Solaris are supported. So I'm glad to find rxtx.org and am just reading up on how make the conversion so Windows users will be able to run the program as well. At the same time I'm just curious if rxtx.org and Sun are both heading in the same direction. Thanks for any background or historical info. Feel free to point me to any www pages if my googling has just completely missed the target! Thanks again, Mike From tjarvi at qbang.org Sat Mar 10 15:35:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 15:35:25 -0700 (MST) Subject: [Rxtx] rxtx and Sun's comm api In-Reply-To: <45F327B0.2060004@udel.edu> References: <45F327B0.2060004@udel.edu> Message-ID: On Sat, 10 Mar 2007, Mike Markowski wrote: > Hi all, > > I joined the list a few days ago and apologize for what is likely a > frequently asked question, though I haven't yet found it anywhere. I > learned about rxtx.org through the readme on Sun's version 2 of their > comms api. They give recommendations in that readme regarding how a > better comms api should be written. Is this the aim of rxtx.org? > > I wrote an app on my linux box using the Sun comms api > (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the > fact that only linux and Solaris are supported. So I'm glad to find > rxtx.org and am just reading up on how make the conversion so Windows > users will be able to run the program as well. At the same time I'm > just curious if rxtx.org and Sun are both heading in the same direction. > > Thanks for any background or historical info. Feel free to point me to > any www pages if my googling has just completely missed the target! > I do not have any news (good or bad) concerning RXTX and Sun working together but perhaps others here do. The main goal of RXTX is to expose POSIX termios interfaces to java users. The future support of javax.comm is questionable. We do not have resources for everything. gnu.io (RXTX 2.1) will be supported going forward and functions the same as CommAPI 2.0. If you have control of the source code you are working with, I would not advise using CommAPI 2.0 javax.comm. We do support CommAPI 2.0 javax.comm for older applications but I do not think that will last much longer for practical reasons. The download interest in CommAPI 2.0 javax.comm support is becomming negligible on this end. There has been discussion of a JSR effort but I do not know of any status change since it was mentioned. One problem with a JSR is that even a light weight process is going to be difficult for RXTX at this time. Maybe that will change in the future but then again it may not. For now, we are just going forward 'as is' in rxtx 2.1 with package gnu.io while trying as a secondary effort to backport the changes to rxtx 2.0 for javax.comm support for users that do not have a choice. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Mar 11 07:19:40 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 11 Mar 2007 08:19:40 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: Hi All, I have been a proponent of a JSR that makes use of RXTX. I have executed the proper agreements with Sun. At this point we are in the: Early Draft Review of Draft Specifications Stage. The best thing to do is to enter the quiet period and create a specification. The question of exactly how we, as a group, want to approach this problem, remains open. Typically, we should have both a specification and a reference implementation. Thus, it would be to our best advantage to have a nice, stable, cross platform RXTX distro that adheres to the groups specification. Now, from a specification standpoint, my personal view on the matter is that we create a series of interfaces, with nice documentation (or at least javadoc). Is this a good idea? Should we have a pure interface specification for the communication API? There are several issues, in my mind, which still weigh on us. Hot-pluggable dongles, long discovery process on pop-up ports, lack of uniformity on device names, lack of uniformity on locking, a precise understanding of how the SerialPortResourceManager works (or even if we should have one). The more questions we answer in our reference implementation, the better our specification will get. RXTX is a good working prototype, but, I don't know if that is what we want to use for a specification. Here is what I have for a CommPortInterface: */ public interface CommPortInterface { /** * @return a string representation of this port. */ String toString(); /** * Gets the name of the communications port. This name should correspond to * something the user can identify, like the label on the hardware. * @return name of the port */ String getName(); /** * @return an input stream that can be used to read data from the * communications port. If the port doesn't support reading data, this * method returns null. *

* The blocking behaviour of this input stream depends on the threshold * and timeout values, as shown below for a read buffer size of n * bytes: * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ThresholdTimeoutBlocking behaviour
StateValueStateValue
disableddisabledblock until data is available
enabledm bytesdisabledblock until min(m, n) bytes are available
disabledenabledt msblock for t ms or until data is available
enabledm bytesenabledt msblock for t ms or until min(m, n) bytes are * available
* @throws java.io.IOException */ InputStream getInputStream() throws IOException; /** * @return an output stream that can be used to send data to the * communications port. If the port doesn't support sending data, this * method returns null. * @throws java.io.IOException */ OutputStream getOutputStream() throws IOException; /** * Closes this communications port. * All PortOwnershipListeners will be? * notified of this change of ownership. Further method calls on this? * object will throw IllegalStateException. Further calls on the? * associated InputStream or OutputStream will throw IOException. *

* Close does not block. Undelivered data is discarded. Blocked read and? * write operations are aborted if the underlying operating systems? * supports an IO abort mechanism. To await the delivery of undelivered? * data call OutputStream.flush() or OutputStream.close() before calling? * Port.close(). */ void close(); /** * Enables receive threshold. * When the specified threshold number of bytes are retrieved, read will * return immediately. * * @param thresh the number of bytes in the input buffer * @throws gnu.io.UnsupportedCommOperationException * if receive threshold is * not supported by the driver * @see #disableReceiveThreshold */ void enableReceiveThreshold(int thresh) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive threshold. * * @see #enableReceiveThreshold */ void disableReceiveThreshold(); /** * @return true if receive threshold is enabled. * * @see #enableReceiveThreshold */ boolean isReceiveThresholdEnabled(); /** * @return the receive threshold value. If receive threshold is diabled * or not supported, this value is meaningless. * * @see #enableReceiveThreshold */ int getReceiveThreshold(); /** * Enables receive timeout. * When the specified number of milliseconds have elapsed, read will * return immediately. * * @param rcvTimeout the number of milliseconds to block for * @throws gnu.io.UnsupportedCommOperationException * if receive timeout is * not supported by the driver * @see #disableReceiveTimeout */ void enableReceiveTimeout(int rcvTimeout) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive timeout. * * @see #enableReceiveTimeout */ void disableReceiveTimeout(); /** * @return true if receive timeout is enabled. * * @see #enableReceiveTimeout */ boolean isReceiveTimeoutEnabled(); /** * @return the receive timeout value. If receive timeout is diabled * or not supported, this value is meaningless. * * @see #enableReceiveTimeout */ int getReceiveTimeout(); /** * Enables receive framing. * The supplied byte value in the input suggests the end of the received * frame, and read returns immediately. Only the low 8 bits of the * supplied value are significant. * * @param framingByte the frame delimiter * @throws gnu.io.UnsupportedCommOperationException * if receive framing is * not supported by the driver * @see #disableReceiveFraming */ void enableReceiveFraming(int framingByte) throws UnsupportedCommOperationException; /** * Disables receive framing. * * @see #enableReceiveFraming */ void disableReceiveFraming(); /** * @return true if receive framing is enabled. * * @see #enableReceiveFraming */ boolean isReceiveFramingEnabled(); /** * @return true if receive framing byte. If receive framing is diabled * or not supported, this value is meaningless. * * @see #enableReceiveFraming */ int getReceiveFramingByte(); /** * Sets the input buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setInputBufferSize(int size); /** * @return the input buffer size. * The driver may choose not to report correct values. */ int getInputBufferSize(); /** * Sets the output buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setOutputBufferSize(int size); /** * @return the output buffer size. * The driver may choose not to report correct values. */ int getOutputBufferSize(); } What do you think of that? Note the wishy washy nature of the spec: The driver may choose to ignore this method. Is that good enough for us? Thanks! - Doug From ra85551 at gmail.com Sun Mar 11 08:44:45 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Sun, 11 Mar 2007 17:44:45 +0300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hello, world! I am writing application that communicates with modem via AT commands. My OS is Linux Kubuntu Feisty Herd, to ensure that my application will run properly under Windows XP I installed VMWare server. When I tried to send AT command and evaluate modem answer under WinXP @ VMWare server, I actually didn't receive anything. I think that VM settings are right, because I do can communicate with modem by using standard HyperTerminall as well as I can do on native Windows. So, why RXTX doesn't work under VM, but works under Linux and pure Windows XP (i tested it there) well? The send/receive method code follows. private String sendATCommand(String command, final String waitFor, final boolean isRegex, boolean isAddCRLF, long timeout) throws BeaconConnectException { final long POLL_PERIOD = 100; final int BUFFER_SIZE = 512; final byte[] buffer = new byte[BUFFER_SIZE]; final InputStream serialInput; final OutputStream serialOutput; try { serialInput = serialPort.getInputStream(); if (command != null) { serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } } catch (IOException e) { throw new MyException("serial I/O error"); } TimerTask task = new TimerTask() { int offset = 0; int bytesRead; public synchronized void run() { try { if (serialInput.available() > 0) { bytesRead = serialInput.read(buffer, offset, BUFFER_SIZE - offset); } else { return; } } catch (IOException e) { // do nothing - maybe next time we'll read something } offset += bytesRead; if (waitFor != null) { String temporary = new String(buffer, 0, offset).trim(); if (isRegex && temporary.matches(waitFor) || temporary.contains(waitFor)) { cancel(); notify(); } } } }; Timer timer = new Timer(); timer.schedule(task, POLL_PERIOD, POLL_PERIOD); synchronized (task) { try { task.wait(timeout); task.cancel(); } catch (InterruptedException e) { } } //Cut off leading and trailing CRs, LFs and zeroes String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); System.out.println(response); return response; } -- Pavel Parkhomenko From tjarvi at qbang.org Sun Mar 11 11:48:22 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:48:22 -0600 (MDT) Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: On Sun, 11 Mar 2007, Pavel Parkhomenko wrote: > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. > > private String sendATCommand(String command, final String waitFor, > final boolean isRegex, boolean isAddCRLF, long timeout) > throws BeaconConnectException > { > final long POLL_PERIOD = 100; > final int BUFFER_SIZE = 512; > final byte[] buffer = new byte[BUFFER_SIZE]; > final InputStream serialInput; > final OutputStream serialOutput; > try > { > serialInput = serialPort.getInputStream(); > if (command != null) > { > serialOutput = serialPort.getOutputStream(); > if (isAddCRLF) > { > command += "\r\n"; > } > System.out.println(command); > serialOutput.write(command.getBytes()); > } > } > catch (IOException e) > { > throw new MyException("serial I/O error"); > } > > TimerTask task = new TimerTask() > { > int offset = 0; > int bytesRead; > public synchronized void run() > { > try > { > if (serialInput.available() > 0) > { > bytesRead = serialInput.read(buffer, offset, > BUFFER_SIZE - offset); > } > else > { > return; > } > } > catch (IOException e) > { > // do nothing - maybe next time we'll read something > } > offset += bytesRead; > if (waitFor != null) > { > String temporary = new String(buffer, 0, offset).trim(); > if (isRegex && temporary.matches(waitFor) || > temporary.contains(waitFor)) > { > cancel(); > notify(); > } > } > } > }; > > Timer timer = new Timer(); > timer.schedule(task, POLL_PERIOD, POLL_PERIOD); > synchronized (task) { > try > { > task.wait(timeout); > task.cancel(); > } > catch (InterruptedException e) > { > } > } > //Cut off leading and trailing CRs, LFs and zeroes > String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); > System.out.println(response); > return response; > } > > > Hi Pavel VMWare should not be a problem. I've used it in the past - though not with a modem. Make sure nothing else is using the modem. Then look in the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an example that should work. Note that modems could care less what OS is on top. If you are trying to match new lines to the OS and sending it to the mode for AT commands, thats probably a mistake. Also it would not hurt to print out the individual bytes that you are sending to make sure they did not get mangled along the path. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 11:55:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:55:48 -0600 (MDT) Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: On Sun, 11 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > I have been a proponent of a JSR that makes > use of RXTX. I have executed the proper agreements with Sun. > > At this point we are in the: > Early Draft Review of Draft Specifications Stage. > > The best thing to do is to enter the quiet period and create > a specification. The question of exactly how we, as a group, > want to approach this problem, remains open. > > Typically, we should have both a specification and a reference > implementation. Thus, it would be to our best advantage to have > a nice, stable, cross platform RXTX distro that adheres to the > groups specification. > > Now, from a specification standpoint, my personal view on the matter is > that we create a series of interfaces, with nice documentation (or at least > javadoc). > > Is this a good idea? Should we have a pure interface specification for > the communication API? > > There are several issues, in my mind, which still weigh on us. > Hot-pluggable dongles, long discovery process on pop-up ports, > lack of uniformity on device names, lack of uniformity on locking, > a precise understanding of how the SerialPortResourceManager > works (or even if we should have one). > > The more questions we answer in our reference implementation, the > better our specification will get. RXTX is a good working prototype, > but, I don't know if that is what we want to use for a specification. > > Here is what I have for a CommPortInterface: > */ > public interface CommPortInterface { Hi Doug, I can start going through the method interfaces later this week and giving feedback. I would suggest that the JSR should not be too generic in nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel drivers that intend to look like EIA232 ports at the kernel driver level. some ideas: EIA232PortInterface TermiosInterface SerialPortInterface Something that differentiates this from thing like USB, I2C, ... which should not have to deal with legacy serial claiming to be the comm api. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 12:52:19 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 12:52:19 -0600 (MDT) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: No news is good news with these posts. I'll start the process of pinging legal a week from Monday on my end if nobody has objections to the proposal. I just want to make sure everyone has time to raise objections. Obviously, anyone can fork from a previous version if they don't like the new license. I suspect we can avoid that though. On Sun, 4 Mar 2007, Trent Jarvi wrote: > > For those that are wondering what is going on here, this > next bit is the meat of the changes. We agreed a long time > ago to put this disclaimer in. We did a so so job. It was > in rxtx 2.0, not well written, ... So some groups using > rxtx that would like to ship rxtx so users don't need to > download, install, go to the mail-list to find why it failed, > ... Then their legal teams tell them section 5 paragraph 2 > is a show stopper. > > That was never the intent. > > > Now going through what remains... > >> and might need a (TM) suffix to make Sun happy. > > Added disclaimer at the ended 'all trademarks belong...' > >> * Line #15ff - static vs. dynamic linking - you did >> not transcribe the text from the "controlled >> interface exception" when writing this text - and >> this was good so, because these terms originally >> refer to the GPL rather than the LGPL. I think though, >> that these 4 lines are the most important ones and >> should thus be really really clear. I hope that I >> meet your original intent with the following >> suggestions: >> 1.) Instead of "A program.." it would be better to >> say "An exectuable.." in order to be closer to >> the LGPL text. > > OK. As you can see I was trying to adjust GNU text there > for the LGPL. > >> 2.) It would be better to say .. "by being dynamically >> linked with it" to clearly indicate that dynamic >> linking is meant. The matter of compilation is >> already covered by the LGPL so mentioning it again >> just leads to confusion. > > used dynamically linked terminology. > >> 3.) It would be better to say .. "is considered a >> work that uses the library in contrast to section >> 5 of the LGPL, so the terms of the LGPL do not >> apply to the resulting executable". > > I tried to address this more upfront with an intent statement. > Let me know if you have problems with it. I also tried to > make it a little more clear what was derived from the GNU > solution by moving the link location closer to GNU's suggestion. > >> >> Note that LGPL section 5 says: ..."is called a >> "work that uses the Library". Such a work, in isolation, >> is not a derivative work of the Library, and therefore >> falls outside the scope of this License." >> The next paragraph of the LGPL is exactly the problematic >> one that I hope is clarified by the exception terms you >> give. >> > > Thats the intent. Here is the combined fixes. Note that only the > material in /*-- --*/ is being touched. The new GPL license is > there but unmodified. > > > ------------------------ begin proposed new license ------------------- > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Lesser General Public > | License as published by the Free Software Foundation; either > | version 2.1 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Lesser General Public License for more details. > | > | An executable that contains no derivative of any portion of RXTX, but > | is designed to work with RXTX by being dynamically linked with it, > | is considered a "work that uses the Library" subject to the terms and > | conditions of the GNU Lesser General Public License. > | > | The following has been added to the RXTX License to remove > | any confusion about linking to RXTX. We want to allow in part what > | section 5, paragraph 2 of the LGPL does not permit in the special > | case of linking over a controlled interface. The intent is to add a > | Java Specification Request or standards body defined interface in the > | future as another exception but one is not currently available. > | > | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface > | > | As a special exception, the copyright holders of RXTX give you > | permission to link RXTX with independent modules that communicate with > | RXTX solely through the Sun Microsytems CommAPI interface version 2, > | regardless of the license terms of these independent modules, and to copy > | and distribute the resulting combined work under terms of your choice, > | provided that every copy of the combined work is accompanied by a complete > | copy of the source code of RXTX (the version of RXTX used to produce the > | combined work), being distributed under the terms of the GNU Lesser General > | Public License plus this exception. An independent module is a > | module which is not derived from or based on RXTX. > | > | Note that people who make modified versions of RXTX are not obligated > | to grant this special exception for their modified versions; it is > | their choice whether to do so. The GNU Lesser General Public License > | gives permission to release a modified version without this exception; this > | exception also makes it possible to release a modified version which > | carries forward this exception. > | > | You should have received a copy of the GNU Lesser General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > | All trademarks belong to their respective owners. > --------------------------------------------------------------------------*/ > > The original GNU Lesser General Public License Follows. > > > GNU LESSER GENERAL PUBLIC LICENSE > Version 2.1, February 1999 > > Copyright (C) 1991, 1999 Free Software Foundation, Inc. > 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > Everyone is permitted to copy and distribute verbatim copies > of this license document, but changing it is not allowed. > > [This is the first released version of the Lesser GPL. It also counts > as the successor of the GNU Library Public License, version 2, hence > the version number 2.1.] > > Preamble > > The licenses for most software are designed to take away your > freedom to share and change it. By contrast, the GNU General Public > Licenses are intended to guarantee your freedom to share and change > free software--to make sure the software is free for all its users. > > This license, the Lesser General Public License, applies to some > specially designated software packages--typically libraries--of the > Free Software Foundation and other authors who decide to use it. You > can use it too, but we suggest you first think carefully about whether > this license or the ordinary General Public License is the better > strategy to use in any particular case, based on the explanations below. > > When we speak of free software, we are referring to freedom of use, > not price. Our General Public Licenses are designed to make sure that > you have the freedom to distribute copies of free software (and charge > for this service if you wish); that you receive source code or can get > it if you want it; that you can change the software and use pieces of > it in new free programs; and that you are informed that you can do > these things. > > To protect your rights, we need to make restrictions that forbid > distributors to deny you these rights or to ask you to surrender these > rights. These restrictions translate to certain responsibilities for > you if you distribute copies of the library or if you modify it. > > For example, if you distribute copies of the library, whether gratis > or for a fee, you must give the recipients all the rights that we gave > you. You must make sure that they, too, receive or can get the source > code. If you link other code with the library, you must provide > complete object files to the recipients, so that they can relink them > with the library after making changes to the library and recompiling > it. And you must show them these terms so they know their rights. > > We protect your rights with a two-step method: (1) we copyright the > library, and (2) we offer you this license, which gives you legal > permission to copy, distribute and/or modify the library. > > To protect each distributor, we want to make it very clear that > there is no warranty for the free library. Also, if the library is > modified by someone else and passed on, the recipients should know > that what they have is not the original version, so that the original > author's reputation will not be affected by problems that might be > introduced by others. > > Finally, software patents pose a constant threat to the existence of > any free program. We wish to make sure that a company cannot > effectively restrict the users of a free program by obtaining a > restrictive license from a patent holder. Therefore, we insist that > any patent license obtained for a version of the library must be > consistent with the full freedom of use specified in this license. > > Most GNU software, including some libraries, is covered by the > ordinary GNU General Public License. This license, the GNU Lesser > General Public License, applies to certain designated libraries, and > is quite different from the ordinary General Public License. We use > this license for certain libraries in order to permit linking those > libraries into non-free programs. > > When a program is linked with a library, whether statically or using > a shared library, the combination of the two is legally speaking a > combined work, a derivative of the original library. The ordinary > General Public License therefore permits such linking only if the > entire combination fits its criteria of freedom. The Lesser General > Public License permits more lax criteria for linking other code with > the library. > > We call this license the "Lesser" General Public License because it > does Less to protect the user's freedom than the ordinary General > Public License. It also provides other free software developers Less > of an advantage over competing non-free programs. These disadvantages > are the reason we use the ordinary General Public License for many > libraries. However, the Lesser license provides advantages in certain > special circumstances. > > For example, on rare occasions, there may be a special need to > encourage the widest possible use of a certain library, so that it becomes > a de-facto standard. To achieve this, non-free programs must be > allowed to use the library. A more frequent case is that a free > library does the same job as widely used non-free libraries. In this > case, there is little to gain by limiting the free library to free > software only, so we use the Lesser General Public License. > > In other cases, permission to use a particular library in non-free > programs enables a greater number of people to use a large body of > free software. For example, permission to use the GNU C Library in > non-free programs enables many more people to use the whole GNU > operating system, as well as its variant, the GNU/Linux operating > system. > > Although the Lesser General Public License is Less protective of the > users' freedom, it does ensure that the user of a program that is > linked with the Library has the freedom and the wherewithal to run > that program using a modified version of the Library. > > The precise terms and conditions for copying, distribution and > modification follow. Pay close attention to the difference between a > "work based on the library" and a "work that uses the library". The > former contains code derived from the library, whereas the latter must > be combined with the library in order to run. > > GNU LESSER GENERAL PUBLIC LICENSE > TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION > > 0. This License Agreement applies to any software library or other > program which contains a notice placed by the copyright holder or > other authorized party saying it may be distributed under the terms of > this Lesser General Public License (also called "this License"). > Each licensee is addressed as "you". > > A "library" means a collection of software functions and/or data > prepared so as to be conveniently linked with application programs > (which use some of those functions and data) to form executables. > > The "Library", below, refers to any such software library or work > which has been distributed under these terms. A "work based on the > Library" means either the Library or any derivative work under > copyright law: that is to say, a work containing the Library or a > portion of it, either verbatim or with modifications and/or translated > straightforwardly into another language. (Hereinafter, translation is > included without limitation in the term "modification".) > > "Source code" for a work means the preferred form of the work for > making modifications to it. For a library, complete source code means > all the source code for all modules it contains, plus any associated > interface definition files, plus the scripts used to control compilation > and installation of the library. > > Activities other than copying, distribution and modification are not > covered by this License; they are outside its scope. The act of > running a program using the Library is not restricted, and output from > such a program is covered only if its contents constitute a work based > on the Library (independent of the use of the Library in a tool for > writing it). Whether that is true depends on what the Library does > and what the program that uses the Library does. > > 1. You may copy and distribute verbatim copies of the Library's > complete source code as you receive it, in any medium, provided that > you conspicuously and appropriately publish on each copy an > appropriate copyright notice and disclaimer of warranty; keep intact > all the notices that refer to this License and to the absence of any > warranty; and distribute a copy of this License along with the > Library. > > You may charge a fee for the physical act of transferring a copy, > and you may at your option offer warranty protection in exchange for a > fee. > > 2. You may modify your copy or copies of the Library or any portion > of it, thus forming a work based on the Library, and copy and > distribute such modifications or work under the terms of Section 1 > above, provided that you also meet all of these conditions: > > a) The modified work must itself be a software library. > > b) You must cause the files modified to carry prominent notices > stating that you changed the files and the date of any change. > > c) You must cause the whole of the work to be licensed at no > charge to all third parties under the terms of this License. > > d) If a facility in the modified Library refers to a function or a > table of data to be supplied by an application program that uses > the facility, other than as an argument passed when the facility > is invoked, then you must make a good faith effort to ensure that, > in the event an application does not supply such function or > table, the facility still operates, and performs whatever part of > its purpose remains meaningful. > > (For example, a function in a library to compute square roots has > a purpose that is entirely well-defined independent of the > application. Therefore, Subsection 2d requires that any > application-supplied function or table used by this function must > be optional: if the application does not supply it, the square > root function must still compute square roots.) > > These requirements apply to the modified work as a whole. If > identifiable sections of that work are not derived from the Library, > and can be reasonably considered independent and separate works in > themselves, then this License, and its terms, do not apply to those > sections when you distribute them as separate works. But when you > distribute the same sections as part of a whole which is a work based > on the Library, the distribution of the whole must be on the terms of > this License, whose permissions for other licensees extend to the > entire whole, and thus to each and every part regardless of who wrote > it. > > Thus, it is not the intent of this section to claim rights or contest > your rights to work written entirely by you; rather, the intent is to > exercise the right to control the distribution of derivative or > collective works based on the Library. > > In addition, mere aggregation of another work not based on the Library > with the Library (or with a work based on the Library) on a volume of > a storage or distribution medium does not bring the other work under > the scope of this License. > > 3. You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. To do > this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version 2, > instead of to this License. (If a newer version than version 2 of the > ordinary GNU General Public License has appeared, then you can specify > that version instead if you wish.) Do not make any other change in > these notices. > > Once this change is made in a given copy, it is irreversible for > that copy, so the ordinary GNU General Public License applies to all > subsequent copies and derivative works made from that copy. > > This option is useful when you wish to copy part of the code of > the Library into a program that is not a library. > > 4. You may copy and distribute the Library (or a portion or > derivative of it, under Section 2) in object code or executable form > under the terms of Sections 1 and 2 above provided that you accompany > it with the complete corresponding machine-readable source code, which > must be distributed under the terms of Sections 1 and 2 above on a > medium customarily used for software interchange. > > If distribution of object code is made by offering access to copy > from a designated place, then offering equivalent access to copy the > source code from the same place satisfies the requirement to > distribute the source code, even though third parties are not > compelled to copy the source along with the object code. > > 5. A program that contains no derivative of any portion of the > Library, but is designed to work with the Library by being compiled or > linked with it, is called a "work that uses the Library". Such a > work, in isolation, is not a derivative work of the Library, and > therefore falls outside the scope of this License. > > However, linking a "work that uses the Library" with the Library > creates an executable that is a derivative of the Library (because it > contains portions of the Library), rather than a "work that uses the > library". The executable is therefore covered by this License. > Section 6 states terms for distribution of such executables. > > When a "work that uses the Library" uses material from a header file > that is part of the Library, the object code for the work may be a > derivative work of the Library even though the source code is not. > Whether this is true is especially significant if the work can be > linked without the Library, or if the work is itself a library. The > threshold for this to be true is not precisely defined by law. > > If such an object file uses only numerical parameters, data > structure layouts and accessors, and small macros and small inline > functions (ten lines or less in length), then the use of the object > file is unrestricted, regardless of whether it is legally a derivative > work. (Executables containing this object code plus portions of the > Library will still fall under Section 6.) > > Otherwise, if the work is a derivative of the Library, you may > distribute the object code for the work under the terms of Section 6. > Any executables containing that work also fall under Section 6, > whether or not they are linked directly with the Library itself. > > 6. As an exception to the Sections above, you may also combine or > link a "work that uses the Library" with the Library to produce a > work containing portions of the Library, and distribute that work > under terms of your choice, provided that the terms permit > modification of the work for the customer's own use and reverse > engineering for debugging such modifications. > > You must give prominent notice with each copy of the work that the > Library is used in it and that the Library and its use are covered by > this License. You must supply a copy of this License. If the work > during execution displays copyright notices, you must include the > copyright notice for the Library among them, as well as a reference > directing the user to the copy of this License. Also, you must do one > of these things: > > a) Accompany the work with the complete corresponding > machine-readable source code for the Library including whatever > changes were used in the work (which must be distributed under > Sections 1 and 2 above); and, if the work is an executable linked > with the Library, with the complete machine-readable "work that > uses the Library", as object code and/or source code, so that the > user can modify the Library and then relink to produce a modified > executable containing the modified Library. (It is understood > that the user who changes the contents of definitions files in the > Library will not necessarily be able to recompile the application > to use the modified definitions.) > > b) Use a suitable shared library mechanism for linking with the > Library. A suitable mechanism is one that (1) uses at run time a > copy of the library already present on the user's computer system, > rather than copying library functions into the executable, and (2) > will operate properly with a modified version of the library, if > the user installs one, as long as the modified version is > interface-compatible with the version that the work was made with. > > c) Accompany the work with a written offer, valid for at > least three years, to give the same user the materials > specified in Subsection 6a, above, for a charge no more > than the cost of performing this distribution. > > d) If distribution of the work is made by offering access to copy > from a designated place, offer equivalent access to copy the above > specified materials from the same place. > > e) Verify that the user has already received a copy of these > materials or that you have already sent this user a copy. > > For an executable, the required form of the "work that uses the > Library" must include any data and utility programs needed for > reproducing the executable from it. However, as a special exception, > the materials to be distributed need not include anything that is > normally distributed (in either source or binary form) with the major > components (compiler, kernel, and so on) of the operating system on > which the executable runs, unless that component itself accompanies > the executable. > > It may happen that this requirement contradicts the license > restrictions of other proprietary libraries that do not normally > accompany the operating system. Such a contradiction means you cannot > use both them and the Library together in an executable that you > distribute. > > 7. You may place library facilities that are a work based on the > Library side-by-side in a single library together with other library > facilities not covered by this License, and distribute such a combined > library, provided that the separate distribution of the work based on > the Library and of the other library facilities is otherwise > permitted, and provided that you do these two things: > > a) Accompany the combined library with a copy of the same work > based on the Library, uncombined with any other library > facilities. This must be distributed under the terms of the > Sections above. > > b) Give prominent notice with the combined library of the fact > that part of it is a work based on the Library, and explaining > where to find the accompanying uncombined form of the same work. > > 8. You may not copy, modify, sublicense, link with, or distribute > the Library except as expressly provided under this License. Any > attempt otherwise to copy, modify, sublicense, link with, or > distribute the Library is void, and will automatically terminate your > rights under this License. However, parties who have received copies, > or rights, from you under this License will not have their licenses > terminated so long as such parties remain in full compliance. > > 9. You are not required to accept this License, since you have not > signed it. However, nothing else grants you permission to modify or > distribute the Library or its derivative works. These actions are > prohibited by law if you do not accept this License. Therefore, by > modifying or distributing the Library (or any work based on the > Library), you indicate your acceptance of this License to do so, and > all its terms and conditions for copying, distributing or modifying > the Library or works based on it. > > 10. Each time you redistribute the Library (or any work based on the > Library), the recipient automatically receives a license from the > original licensor to copy, distribute, link with or modify the Library > subject to these terms and conditions. You may not impose any further > restrictions on the recipients' exercise of the rights granted herein. > You are not responsible for enforcing compliance by third parties with > this License. > > 11. If, as a consequence of a court judgment or allegation of patent > infringement or for any other reason (not limited to patent issues), > conditions are imposed on you (whether by court order, agreement or > otherwise) that contradict the conditions of this License, they do not > excuse you from the conditions of this License. If you cannot > distribute so as to satisfy simultaneously your obligations under this > License and any other pertinent obligations, then as a consequence you > may not distribute the Library at all. For example, if a patent > license would not permit royalty-free redistribution of the Library by > all those who receive copies directly or indirectly through you, then > the only way you could satisfy both it and this License would be to > refrain entirely from distribution of the Library. > > If any portion of this section is held invalid or unenforceable under any > particular circumstance, the balance of the section is intended to apply, > and the section as a whole is intended to apply in other circumstances. > > It is not the purpose of this section to induce you to infringe any > patents or other property right claims or to contest validity of any > such claims; this section has the sole purpose of protecting the > integrity of the free software distribution system which is > implemented by public license practices. Many people have made > generous contributions to the wide range of software distributed > through that system in reliance on consistent application of that > system; it is up to the author/donor to decide if he or she is willing > to distribute software through any other system and a licensee cannot > impose that choice. > > This section is intended to make thoroughly clear what is believed to > be a consequence of the rest of this License. > > 12. If the distribution and/or use of the Library is restricted in > certain countries either by patents or by copyrighted interfaces, the > original copyright holder who places the Library under this License may add > an explicit geographical distribution limitation excluding those countries, > so that distribution is permitted only in or among countries not thus > excluded. In such case, this License incorporates the limitation as if > written in the body of this License. > > 13. The Free Software Foundation may publish revised and/or new > versions of the Lesser General Public License from time to time. > Such new versions will be similar in spirit to the present version, > but may differ in detail to address new problems or concerns. > > Each version is given a distinguishing version number. If the Library > specifies a version number of this License which applies to it and > "any later version", you have the option of following the terms and > conditions either of that version or of any later version published by > the Free Software Foundation. If the Library does not specify a > license version number, you may choose any version ever published by > the Free Software Foundation. > > 14. If you wish to incorporate parts of the Library into other free > programs whose distribution conditions are incompatible with these, > write to the author to ask for permission. For software which is > copyrighted by the Free Software Foundation, write to the Free > Software Foundation; we sometimes make exceptions for this. Our > decision will be guided by the two goals of preserving the free status > of all derivatives of our free software and of promoting the sharing > and reuse of software generally. > > NO WARRANTY > > 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO > WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. > EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR > OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY > KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE > IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE > LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME > THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. > > 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN > WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY > AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU > FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR > CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE > LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING > RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A > FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF > SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH > DAMAGES. > > END OF TERMS AND CONDITIONS > > How to Apply These Terms to Your New Libraries > > If you develop a new library, and you want it to be of the greatest > possible use to the public, we recommend making it free software that > everyone can redistribute and change. You can do so by permitting > redistribution under these terms (or, alternatively, under the terms of the > ordinary General Public License). > > To apply these terms, attach the following notices to the library. It is > safest to attach them to the start of each source file to most effectively > convey the exclusion of warranty; and each file should have at least the > "copyright" line and a pointer to where the full notice is found. > > > Copyright (C) > > This library is free software; you can redistribute it and/or > modify it under the terms of the GNU Lesser General Public > License as published by the Free Software Foundation; either > version 2.1 of the License, or (at your option) any later version. > > This library is distributed in the hope that it will be useful, > but WITHOUT ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > Lesser General Public License for more details. > > You should have received a copy of the GNU Lesser General Public > License along with this library; if not, write to the Free Software > Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > > Also add information on how to contact you by electronic and paper mail. > > You should also get your employer (if you work as a programmer) or your > school, if any, to sign a "copyright disclaimer" for the library, if > necessary. Here is a sample; alter the names: > > Yoyodyne, Inc., hereby disclaims all copyright interest in the > library `Frob' (a library for tweaking knobs) written by James Random Hacker. > > , 1 April 1990 > Ty Coon, President of Vice > > That's all there is to it! > ------------------------ end of proposed license ------------------ > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From gjhanna at gmail.com Sun Mar 11 14:21:17 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Mon, 12 Mar 2007 09:21:17 +1300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hi Pavel, We are using RXTX under VMWare server in production, quite satisfactorily. We're using Red Hat Enterprise Server 4, and ... Whatever the "enterprise" VMWare product is. Regards, Greg H > Subject: [Rxtx] RXTX under VMWare server > To: rxtx at qbang.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. [ ... snip ... ] -- Pavel Parkhomenko -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070311/4cebb6f9/attachment.html From gergg at cox.net Sun Mar 11 23:39:19 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 12 Mar 2007 00:39:19 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: <45F4E787.6050502@cox.net> Trent Jarvi wrote: > I can start going through the method interfaces later this week and giving > feedback. I would suggest that the JSR should not be too generic in > nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel > drivers that intend to look like EIA232 ports at the kernel driver level. > > some ideas: > > EIA232PortInterface > TermiosInterface > SerialPortInterface > > Something that differentiates this from thing like USB, I2C, ... which > should not have to deal with legacy serial claiming to be the comm api. I'm going to throw out a suggestion, which I am mostly serious about. What would happen if we took the appropriate bits of the J2ME connector API, and just used that as the new COMM API so that finally JSE and JME had a common foundation for these kinds of things? Gregg Wonderly From ra85551 at gmail.com Mon Mar 12 09:08:37 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Mon, 12 Mar 2007 18:08:37 +0300 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Should any application use the modem, HyperTerminal won't be able to talk to the modem. But it actually can send and receive AT comands, while my application cannot :-( > Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Thansk for the reference. I examined that example and found that there's no significant differences between my read/write implementation and that one, except that SimpleSnuV1 listens for serialEvent's, but not for sake of data retrieval, just for printing them out - I don't know why ;-) > Note that modems could care less what OS is on top. If you are trying to > match new lines to the OS and sending it to the mode for AT commands, > thats probably a mistake. I do send strings to serial port, not to OS, and do try to get answers back. If it is the mistake, what's the right way? > Also it would not hurt to print out the > individual bytes that you are sending to make sure they did not get > mangled along the path. Yeah, I am printing these bytes before doing write, but it means that I only see what I intend to write. How can I ensure that these bytes have gone out of the box and reached my modem? BTW, I found that my send/receive method is complex enough, so I've rewritten it. Please, see the following code and point any mistakes, because I don't know where can they remain yet. private static final int LARGE_TIMEOUT = 15000; private static final int SMALL_TIMEOUT = 500; ... private String sendATCommand(String command, String waitFor, boolean isRegex, boolean isAddCRLF) throws BeaconConnectException { byte[] buffer = new byte[512]; int offset; String result = ""; try { if (waitFor != null) { serialPort.enableReceiveTimeout(LARGE_TIMEOUT); } else { serialPort.enableReceiveTimeout(SMALL_TIMEOUT); } if (command != null) { OutputStream serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } offset = 0; InputStream serialInput = serialPort.getInputStream(); while (serialInput.available() != -1) { int bytesRead = serialInput.read(buffer, offset, buffer.length - offset); if (bytesRead == 0) { break; } offset += bytesRead; result = new String(buffer, 0, offset).trim(); if (waitFor != null) { System.out.println(result); if (isRegex && result.matches(waitFor) || result.contains(waitFor)) { break; } } } } catch (UnsupportedCommOperationException e) { throw new MyException("unsupported operation"); } catch (IOException e) { throw new MytException("serial I/O error"); } return result; } -- Pavel Parkhomenko From clayno at hotpop.com Thu Mar 15 02:47:34 2007 From: clayno at hotpop.com (Christopher Layno) Date: Thu, 15 Mar 2007 16:47:34 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi, we're using the latest release of rxtx (2.1-7r2) for our system that has two applications using the library. one application sends requests to the modem while the other simply checks the modem status. we deployed our system on a pentium machine with red hat linux 9.0 installed. now the problem arises when these two applications try to access the same modem at the same time. one of them will eventually have to throw the PortInUseException as shown below: 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException gnu.io.PortInUseException: root PID = 743 Program = java root PID = 743 Program = java root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) this was expected. what we didn't expect though was that if we repeat the scenario 5 times, always 5 times, the application would also throw a VM error: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4473CD21 Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so Current Java thread: at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) - locked <0x44cfd4c8> (a gnu.io.CommPortIdentifier) at ************ at ************ - locked <0x4476a468> (a **********) at ************ at ************ at ************ at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java :261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages( TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run( TCPTransport.java:701) at java.lang.Thread.run(Thread.java:534) note: i replaced some sensitive data with asterisks our team has looked everywhere on the internet, including your mail archives, for a solution to this problem but to no avail. i really hope you could help us out on this one. thanks in advance! best regards, chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070315/1936460a/attachment.html From tjarvi at qbang.org Fri Mar 16 04:30:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 04:30:25 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: On Thu, 15 Mar 2007, Christopher Layno wrote: > hi, > > we're using the latest release of rxtx (2.1-7r2) for our system that has two > applications using the library. one application sends requests to the modem > while the other simply checks the modem status. we deployed our system on a > pentium machine with red hat linux 9.0 installed. > > now the problem arises when these two applications try to access the same > modem at the same time. one of them will eventually have to throw the > PortInUseException as shown below: > > 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException > gnu.io.PortInUseException: root PID = 743 Program = java root PID = > 743 Program = java root PID = 743 Program = ??? root PID = 743 Program > = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root > PID = 743 Program = ??? root PID = 743 Program = ??? > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > > this was expected. what we didn't expect though was that if we repeat the > scenario 5 times, always 5 times, the application would also throw a VM > error: > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x4473CD21 > Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 > Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so > > Current Java thread: > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) Hi Chris The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. The code is originally by Werner Almesberger. He gave us permission to use it in rxtx. You might look at what has changed since 1998 in his fuser application. Or you can just do like other OSs and do the following in fuserImp.c JNIEXPORT jstring JNICALL Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv *env, jobject obj, jstring arg) { return (*env)->NewStringUTF(env, "Unknown Application"); } It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. -- Trent Jarvi tjarvi at qang.org From Adrien.TOS at ingenico.com Fri Mar 16 05:11:12 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Fri, 16 Mar 2007 12:11:12 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903CBC312@frsnprexc1.usr.ingenico.loc> Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070316/972ab214/attachment.html From joachim at buechse.de Fri Mar 16 05:13:24 2007 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 16 Mar 2007 12:13:24 +0100 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. From tjarvi at qbang.org Fri Mar 16 16:36:29 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 16:36:29 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Fri Mar 16 16:02:23 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 16 Mar 2007 18:02:23 -0400 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Not all platforms are Unix based. Also mixing native library usage and command-line calls is not an elegant solution, IMHO. One or the other, but not both. Andre On 16-Mar-07, at 07:13 , Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is > trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We >> only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From clayno at hotpop.com Sun Mar 18 22:17:28 2007 From: clayno at hotpop.com (Christopher Layno) Date: Mon, 19 Mar 2007 12:17:28 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi everyone, thank you so much for your replies. they were really helpful. anyway, before i sent the email, my team was already implementing a temporary solution by using joachim's suggestion. we invoked a lsof command from our java code although i share the same concern with trent and andre-john about portability issues. that's why i said it's just temporary. my superiors have yet to approve our bug fix. so my question now is this: is recompiling the rxtx source code the only way to solve this problem? because if it's the only solution, then i think my superiors would rather have a new release from the rxtx community itself that fixes this bug(?) rather than have my team recompile the source code. best regards, chris Trent Jarvi wrote: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. ... It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070318/237463b2/attachment.html From tjarvi at qbang.org Mon Mar 19 16:20:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Mar 2007 16:20:52 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: Hi Chris I can compile a new version after the 21st if you do not feel comfortable doing so. Please send me an email reminder off-line then. On Mon, 19 Mar 2007, Christopher Layno wrote: > hi everyone, > > thank you so much for your replies. they were really helpful. > > anyway, before i sent the email, my team was already implementing a > temporary solution by using joachim's suggestion. > we invoked a lsof command from our java code although i share the same > concern with trent and andre-john about > portability issues. that's why i said it's just temporary. my superiors have > yet to approve our bug fix. > > so my question now is this: is recompiling the rxtx source code the only way > to solve this problem? because if it's the only > solution, then i think my superiors would rather have a new release from the > rxtx community itself that fixes this bug(?) > rather than have my team recompile the source code. > > best regards, > > chris > > Trent Jarvi wrote: > > Hi Joachim > > It would be nice to have that functionality but calling the program > introduces too many issues imho. Explaining to someone why rxtx invoked a > rogue lsof does not sound very interesting. > > On Fri, 16 Mar 2007, Joachim Buechse wrote: > > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: > > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. > > _______________________________________________ > Rxtx mailing list > Rxtx 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 Eric.Arseneau at sun.com Tue Mar 20 11:47:33 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Tue, 20 Mar 2007 10:47:33 -0700 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 Message-ID: <46001E35.9040608@sun.com> Anyone have any experience with RXTX working with JDK 6 on other platforms ? From mm at UDel.Edu Tue Mar 20 12:18:29 2007 From: mm at UDel.Edu (Mike Markowski) Date: Tue, 20 Mar 2007 14:18:29 -0400 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 In-Reply-To: <46001E35.9040608@sun.com> References: <46001E35.9040608@sun.com> Message-ID: <46002575.4000306@udel.edu> Eric Arseneau wrote: > Anyone have any experience with RXTX working with JDK 6 on other platforms ? I'm using 32 bit intel, gentoo linux, jdk6 with no problems. My applications only use a serial port, though, nothing on the parallel port. Mike From falko.guderian at gmx.de Wed Mar 21 08:17:35 2007 From: falko.guderian at gmx.de (Falko Guderian) Date: Wed, 21 Mar 2007 15:17:35 +0100 Subject: [Rxtx] RXTX binaries for SH4 Message-ID: <46013E7F.40102@gmx.de> Dear developers, I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no possiblities to compile the source code. Better, I'm not able to do this at the moment. Can you provide me with rxtxSerial.dll (SH4) in the rxtx-2.1-8-testing version? (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) The reason for the testing version is I need custom baud rates. Thanks for help. Kind regards, Falko Guderian From tjarvi at qbang.org Wed Mar 21 21:38:37 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Mar 2007 21:38:37 -0600 (MDT) Subject: [Rxtx] RXTX binaries for SH4 In-Reply-To: <46013E7F.40102@gmx.de> References: <46013E7F.40102@gmx.de> Message-ID: On Wed, 21 Mar 2007, Falko Guderian wrote: > Dear developers, > > I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no > possiblities to compile the source code. Better, I'm not able to do this > at the moment. Can you provide me with rxtxSerial.dll (SH4) in the > rxtx-2.1-8-testing version? > (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) > > The reason for the testing version is I need custom baud rates. > > Thanks for help. > Hi Falko WinCE binary format is not supported by gcc. That makes compiling limited to those familiar with the WinCE tools. I hope someone is able to provide them for you but it is not likely. WinCE has been compiled by others in the past but rxtx.org builds have never included WinCE. There is some information with the source concerning WinCE builds if you decide to do it. We can share your results too if you like. The source in the WinCE has never been updated for the custom baud rate. That would need changes from the main source I presume. If you look at the source, you will note that Michal Hobot created a mini fork in the source to handle wince but it has not been updated for 3 years. -- Trent Jarvi tjarvi at qbang.org From Adrien.TOS at ingenico.com Thu Mar 22 07:08:55 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Thu, 22 Mar 2007 14:08:55 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Hi everybody, Do you have any comments on this issue? Thanks! AT ________________________________ De : Adrien TOS Envoy? : vendredi 16 mars 2007 12:11 ? : 'rxtx at qbang.org' Cc : Adrien TOS Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070322/2306c538/attachment.html From jeremy.reeve at zen.co.uk Mon Mar 19 07:36:04 2007 From: jeremy.reeve at zen.co.uk (Jeremy S. Reeve) Date: Mon, 19 Mar 2007 13:36:04 +0000 Subject: [Rxtx] rxtx failing to compile on Fedora Core 6 Message-ID: <1174311364.21865.6.camel@d9thc> When trying to compile latest source : rxtx-2.1-7r2 I get the following when running configure: ---------------- checking os.version 2.6.18-1.2200.fc5smp WARNING: configure is having a hard time determining which directory contains the file jni_md.h. Edit Makefile and fix the variable JAVANATINC to point to the correct directory. The following options are available: /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/ /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/linux/ If there are more than one option available the first was selected. WARNING: Kernel include files do not match the current kernel configure: creating ./config.status ------------------------ which seems OK checking the resultant Makefile but when attempting to build with gmake install I get the following output : ---------------------- 34 problems (34 warnings)/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/javah -classpath .:/home/jsr/rxtxsrc/rxtx-2.1-7r2:/home/jsr/rxtxsrc/rxtx-2.1-7r2/src:/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/ext/RXTXcomm.jar -d i686-pc-linux-gnu -jni `(for i in CommDriver CommPortEnumerator CommPortIdentifier CommPort CommPortOwnershipListener Configure I2C I2CPortEvent I2CPortEventListener I2CPort LPRPort NoSuchPortException ParallelPortEvent ParallelPortEventListener ParallelPort PortInUseException Raw RawPortEvent RawPortEventListener RawPort RS485 RS485PortEvent RS485PortEventListener RS485Port RXTXCommDriver RXTXPort RXTXVersion SerialPortEvent SerialPortEventListener SerialPort UnsupportedCommOperationException UnSupportedLoggerException Zystem;do \ if grep > /dev/null native.* \( /home/jsr/rxtxsrc/rxtx-2.1-7r2/./src/$i.java; then \ echo gnu.io.$i; \ fi; \ done)` i686-pc-linux-gnu/gnu_io_CommPortIdentifier.h: No such file or directory make: *** [/home/jsr/rxtxsrc/rxtx-2.1-7r2/gnu/io/CommDriver.class] Error 1 ------------------------ Any ideas or pointers? Regards, Jeremy From tjarvi at qbang.org Sat Mar 24 08:12:54 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 Mar 2007 08:12:54 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > From Adrien.TOS at ingenico.com Sat Mar 24 11:53:22 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Sat, 24 Mar 2007 18:53:22 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> I do not have the threshold setting enabled, I have explicitely disabled it with: port_.disableReceiveThreshold(); I have also run the same tests with the threshold setting enabled, but they also fail in the same way as described below. So it seems there is a problem with timeout handling on Win32? ________________________________ From: rxtx-bounces at qbang.org on behalf of Trent Jarvi Sent: Sat 3/24/2007 3:12 PM To: RXTX Developers and Users Subject: Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 8312 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20070324/f9e39c9b/attachment.bin From greg.johnson at manchester.ac.uk Sun Mar 25 13:41:36 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Sun, 25 Mar 2007 21:41:36 +0200 Subject: [Rxtx] Mac intel weirdness Message-ID: Hi folks, I'm trying to get rxtx to work on my macbook pro with a USB-serial dongle on it. I am using the 2.1-8 code from the CVS (though it seems to report itself as 2.1-7: makes it difficult to prove to oneself that the changes have 'taken'! - line 4210 in SerialImp.c, line 40 in RXTXVersion.java) I am trying the 2.1-8 because of horrible lock problems in 2.1-7. However, the serialport closure code seems to be broken - it won't close because it believes the (previously opened!) port doesn't exist. Here is what I'm trying: 0. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "false" 1. Open a port Serialport serialport = (SerialPort) commportidentifier.open ("test",100); 2. Talk to a device ... 3. Close port serialport.close(); 4. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "true" - why is this? 5. Try to reopen port Serialport serialport2 = (SerialPort) commportidentifier.open("test", 100); throws PortInUseException. I've dug around a bit in the source, and it seems the SerialPort.close () should call the CommPortIdentifier.internalClosePort() (line 67 of CommPort.java). However, I crash out with the NoSuchPortException when getPortIdentifier is called. Which seems quite weird to me, seeing as it is called on this - which was create just beforehand. Does anyone know how to fix this? Cheers, greg From knute at frazmtn.com Sat Mar 24 10:32:38 2007 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 24 Mar 2007 09:32:38 -0700 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc>, Message-ID: <4604F036.17833.135298@knute.frazmtn.com> > >The behavior of timeout depends upon the setting of the threshold. Do you >have the threshold setting? > This is the same bug I reported last fall. There was a fellow that sent me an email asking if it had been fixed. I told him I didn't think so. He got somebody to write a fix for him but I have not been able to contact him again for the actual changes. The inaccurate timeout and the failure of blocking when no timeouts are set is a serious bug in my humble opinion and renders the software unusable for my applications. I'd really like to have an alternative to the Sun comm api but there just isn't one that I know of. -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Mar 26 16:17:00 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 26 Mar 2007 16:17:00 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> Message-ID: >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. From ra85551 at gmail.com Tue Mar 27 10:18:36 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Tue, 27 Mar 2007 20:18:36 +0400 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Ultimately I found a solution. At first, that wasn't actually the VMWare + WinXP + RXTX issue, that was WinXP + RXTX issue. But on pure XP it sometimes workes, sometimes not, while under VMWare I had never seen my snippet working at all. SimpleSnuV1.java would not help me, because there is only one line I missed, and SimpleSnuV1.java also doesn't contain it! It is as follows: serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_OUT | SerialPort.FLOWCONTROL_RTSCTS_IN); Thank you for your attention. -- Pavel Parkhomenko From griff at op.pl Wed Mar 28 01:28:19 2007 From: griff at op.pl (griff@op.pl) Date: Wed, 28 Mar 2007 09:28:19 +0200 Subject: [Rxtx] No blocking read on Windows. Message-ID: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/5d07d571/attachment.html -------------- next part -------------- Hi, I have problem that InputStram.read() (SerialPort)?returns -1 instead blocking and waiting for data. I found that this problem was ?known in 2005 : ? >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > >> Hi Trent >> >> Thanks for the fast response. >> Here's a Q&D test program for the blocking read on windows that just >> attempts to read one byte, and prints the resulting byte. On my system it >> returns -1, where I expect that it keeps waiting for data. >> >This isn't happening on Linux so the bug is in src/termios.c.? I'll have >something this weekend to fix that. I'm using RXTX 2.1.7r2 and the problem still is here. Im using Windows XP and java 1.5 disableReciveTimeout() and disableReciveTreshhold() dont help. ? best regards ? Piotr Zielniok From Adrien.TOS at ingenico.com Wed Mar 28 01:40:46 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Wed, 28 Mar 2007 09:40:46 +0200 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903E88880@frsnprexc1.usr.ingenico.loc> Looking at the code, it seems there is no support for infinite timeout? And maybe the count++ < 20 condition is breaking out of the loop too early? The only condition to break out of the loop should either be the timeout has expired or the number of requested bytes has been received. -----Message d'origine----- De : rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] De la part de Trent Jarvi Envoy? : mardi 27 mars 2007 00:17 ? : RXTX Developers and Users Objet : Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From j.kenneth.gentle at acm.org Wed Mar 28 06:44:15 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 28 Mar 2007 08:44:15 -0400 Subject: [Rxtx] No blocking read on Windows. In-Reply-To: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> References: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> Message-ID: <200703281844.l2SIiITW028614@qbang.org> Just another "ME TOO!" - I'm seeing this problem on Windows XP, jre for windows XP/Embedded. I cranked receiveTimeout up to Integer.MAX_INT, but it doesn't seem to wait that long At 03:28 2007-03-28, you wrote: >Hi, >I have problem that InputStram.read() (SerialPort) returns -1 >instead blocking and waiting for data. I found that this problem >was known in 2005 : > > >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > > > >> Hi Trent > >> > >> Thanks for the fast response. > >> Here's a Q&D test program for the blocking read on windows that just > >> attempts to read one byte, and prints the resulting byte. On my system it > >> returns -1, where I expect that it keeps waiting for data. > >> > > >This isn't happening on Linux so the bug is in src/termios.c. I'll have > >something this weekend to fix that. > >I'm using RXTX 2.1.7r2 and the problem still is here. >Im using Windows XP and java 1.5 >disableReciveTimeout() and disableReciveTreshhold() dont help. > >best regards > >Piotr Zielniok > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From greg.johnson at manchester.ac.uk Wed Mar 28 14:43:29 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Wed, 28 Mar 2007 22:43:29 +0200 Subject: [Rxtx] Cannot close and reopen serial port Message-ID: <377F9765-7A9D-4CE9-9176-FFB63A2594F0@manchester.ac.uk> Dear all, It appears I cannot close a port properly: SerialPort serialport = portid.open("myprog",100); // do some stuff, all works fine serialport.close(); // all seems fine but... SerialPort sp2 = portid.open("myprog",100); throws PortInUseException. And when I dig into the rxtx code, I find in CommPort.java, in close(): CommPortIdentifier cp = CommPortIdentifier.getPortIdentifier(this); (line 64 or there abouts) but this throws a NoSuchPortException which is caught but ignored (line 74ish). Can anyone suggest how this could happen: a port that was valid, opened, and used, throws a NSPE when it comes to closing it? I'm pulling my (remaining) hair out over this one! Cheers, greg PS And thanks for RXTX - it's great to have! PPS (21.-7. winxp/osx both, java 1.5) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/c28852fc/attachment.html From rxtx at vrijheidslaan.net Fri Mar 30 16:52:50 2007 From: rxtx at vrijheidslaan.net (Rob) Date: Fri, 30 Mar 2007 22:52:50 -0000 Subject: [Rxtx] Cvs Question Message-ID: <61896.80.126.150.87.1175295162.squirrel@webmail.provalue.nl> Hi There, Im trying to get the latest version to work on mac osx. Problem is that i can't checkout version 2.1.8. Probably my fault but can some one please give me the alternative commands for: [user at myhost]$ export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot [user at myhost]$ cvs login Thanx, Rob From ra85551 at gmail.com Thu Mar 1 03:47:06 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Thu, 1 Mar 2007 13:47:06 +0300 Subject: [Rxtx] enableReceiveTimeout() issue Message-ID: Hello, world! I found a limitation of 16300 ms for CommPort's enableReceiveTimeout() method, while in original javax.comm docs there are no any references to that. Is that a bug or feature? I actually need longer timeouts sometimees. -- Pavel Parkhomenko From lyon at docjava.com Thu Mar 1 07:54:17 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 01 Mar 2007 09:54:17 -0500 Subject: [Rxtx] parametric singleton design pattern In-Reply-To: References: <22d55aea0702081207q5e7f6785l352d498d6f5f9fb1@mail.gmail.com> <22d55aea0702100034o3bcf42f3j1d1a6257029a67b0@mail.gmail.com> Message-ID: Hi All, I have been thinking about the use of a design pattern to cache resources that are consumed by processes. Toward that end, I have arrived at a parametric singleton design pattern, which I mentioned on this list some time ago. The idea has been published at: http://www.jot.fm/issues/issue_2007_03/column2 I can't help but think that there should be an API available for dealing with the tracking of serial port usage. Perhaps it is a kind of resource manager called the: SerialPortManager basic prototypes already exist in this vain. See, for example: http://www.ce.rit.edu/research/projects/2005_fall/rt_poolsystem/doc/PoolMon/SerialPortManager.html http://www.eventhelix.com/RealtimeMantra/PatternCatalog/serial_port_design_pattern.htm And others shown by a google search on "SerialPortManager" Cheers! - Doug From Eric.Arseneau at sun.com Thu Mar 1 10:15:03 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:15:03 -0800 Subject: [Rxtx] Any known Java 6 issues with RXTX 2.1-7r2 ? Message-ID: <45E70A17.1060206@sun.com> I just did a test on a recent build of Solaris 11 x86 and it seems that I can connect to my serial device fine when Java 5 is the default, but when Java 6 is the default, no go. Any information ? From Eric.Arseneau at sun.com Thu Mar 1 10:19:58 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:19:58 -0800 Subject: [Rxtx] Mac OS X and missing data Message-ID: <45E70B3E.7040908@sun.com> We have a device which is USB based but presents itself as a serial port to a machine. On my MacBook Pro I can get excellent throughput if I get my device to send data as quickly as possible. On the desktop side, if I do an type of disk IO to log the data I get, I end up with some missing data at some point. I hooked up a USB analyzer and did confirm that all the data is sent as expected to the desktop from the device. I found a work around for this, buffer the data in memory and only write the data out when I've received it all. However, when the same code and same device is attempted on a co-workers MacBook Pro (same hardware specs), I get errors and must slow down dramatically the device side's sending of data. Any ideas/recommendations on what I can do to get rid of this error ? From what I can tell, it seems that RXTX is not able to wake up to the interrupts coming in indicating data is ready, quickly enough, is there anything I can do ? From chinkaiw at hotmail.com Fri Mar 2 00:57:43 2007 From: chinkaiw at hotmail.com (Wang Chinkai) Date: Fri, 02 Mar 2007 07:57:43 +0000 Subject: [Rxtx] dynamic detect rs232 port Message-ID: Hi all I have a question about detecting rs232 port dynamicly. I have to aceess some port and detect rs232 port at the same time. Some usb device simulates rs232 port , and I can not know what the port name it gets until it connects,so I have to detect it dynamic,but I have to access another rs232 device at the same time. I found a problem. If I use CommPortIdentifier.getPortIdentifiers() to get new port list , and the other rs232 access function will not close port correctly. So , How can I solve it . Thanks. _________________________________________________________________ ?? 2GB ???? Windows Live Mail ????????????? http://ideas.live.com/programpage.aspx?versionid=5d21c51a-b161-4314-9b0e-4911fb2b2e6d From eu259473 at tele2.it Fri Mar 2 06:16:40 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 02 Mar 2007 14:16:40 +0100 Subject: [Rxtx] rxtx on HP tru 64 unix Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070302/706c7a70/attachment-0001.html From tjarvi at qbang.org Fri Mar 2 08:39:33 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 08:39:33 -0700 (MST) Subject: [Rxtx] rxtx on HP tru 64 unix In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, "Giuseppe Marchese" wrote: > Hi > > I try to install rxtx on hp tru 64 but make fails, > There are somebody that do the same and work. > > > Sorry for may english! > > Hi Giuseppe Could you provide a log of the failure? script ./configure make # use gnu make exit The information will be in the typescript created. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 2 19:56:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 19:56:52 -0700 (MST) Subject: [Rxtx] dynamic detect rs232 port In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, Wang Chinkai wrote: > Hi all > > I have a question about detecting rs232 port dynamicly. > > I have to aceess some port and detect rs232 port at the same time. > Some usb device simulates rs232 port , and I can not know > what the port name it gets until it connects,so I have to detect it > dynamic,but I have to access > another rs232 device at the same time. > > I found a problem. Hi Wang This is a known problem. The code is braindead there. In fact there needs to be events even in a rudamentary way when you add a usb dongle. I'm burried in tasks not far from rxtx but not in rxtx. I can't get to the problem but we would accept patches if you dig into it. [I'm getting to the license question earlier too; I don't have another 10%] -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Fri Mar 2 23:19:01 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 01:19:01 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Hi, Under ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable USB -> serial converter(using virtual com port drivers), with using example code pretty much straight out of http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port opens fine, enumerations all work, etc. My application calls for a large amount of data to be transferred in a short amount of time at 2,000,000 baud. My hardware sends approximately 15,232 bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL converter work fine, and the application works using C++. In C++, I do a hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); to open the port, and a boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); to read the port. The variable buffer fills with the 15238 bytes, and returns. If I do a resultz = is.read(cbuf,0,15238); in java with RXTX where is = new BufferedReader(new InputStreamReader(port.getInputStream())); and where resultz is an int, and cbuf is a char [] cbuf, resultz gets EXACTLY 3968 bytes the first time called. If I call it multiple times, I get roughly 11k total(less than what is sent), never more than the 3968 bytes per is.read() call. My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 bytes. I've played with inputbuffersize, receive threshold, receivetimeout, and so on. The FTDI virtual com port drivers that I'm using are rock solid, and have had zero problems with them using a variety of applications, some of my own, some professionally written, etc. No flow control is used anyplace, no RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. No exceptions are being thrown. What am I doing wrong, and what I can adjust to receive the full 15k bytes in one single read? Thanks! Keith From Eric.Arseneau at sun.com Fri Mar 2 23:32:07 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Fri, 02 Mar 2007 22:32:07 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <45E91667.20501@sun.com> This is the same type of thing that is happening to me on Mac OS X and does not seem to behave the same on different machines. I posted a day or two ago on this with subject "Mac OS X and missing data". Would love to hear if there is a solution to this :) From tjarvi at qbang.org Sat Mar 3 10:54:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 10:54:17 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > Hi, > > Under > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable > USB -> serial converter(using virtual com port drivers), with using example > code pretty much straight out of > http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port > opens fine, enumerations all work, etc. > > My application calls for a large amount of data to be transferred in a short > amount of time at 2,000,000 baud. My hardware sends approximately 15,232 > bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL > converter work fine, and the application works using C++. > > In C++, I do a > > hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, > OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); > > to open the port, and a > > boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); > > to read the port. > > The variable buffer fills with the 15238 bytes, and returns. > > If I do a > > resultz = is.read(cbuf,0,15238); in java with RXTX > > where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > > and where resultz is an int, and cbuf is a char [] cbuf, resultz gets > EXACTLY 3968 bytes the first time called. If I call it multiple times, I get > roughly 11k total(less than what is sent), never more than the 3968 bytes > per is.read() call. > > My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 > bytes. > > I've played with inputbuffersize, receive threshold, receivetimeout, and so > on. The FTDI virtual com port drivers that I'm using are rock solid, and > have had zero problems with them using a variety of applications, some of my > own, some professionally written, etc. No flow control is used anyplace, no > RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. > > No exceptions are being thrown. > > What am I doing wrong, and what I can adjust to receive the full 15k bytes > in one single read? > > Thanks! > Hi Keith I would expect a 20 meg application is going to have different behavior with the OS than a smaller application with respect to the kernel memory managment, schedualing, ... Something subtle could be causing problems. With respect to the recieve timeout and threshold, if you set the timeout to zero and the threshold to the size of data you expect, read should not return until it get that data. You may try with a stand alone application that tests just that with the C/C++ API. If the read is returning with less data when tested for short reads, you have found a bug in the device driver more than likely. The USB dongle vendor would probably be interested in knowing about this. As mentioned, these devices are getting very good; almost bug free. I suspect you found a bug though if you did use the threshold and timeout properly. The missing data is typical when not using flow control. When the OS buffering fills, the hardware will start dropping bytes. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:38:52 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:38:52 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> update: I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now instead of 3968. This makes sense. 128 bytes of overhead + 3968 bytes of data = 4096 transfer size 32 bytes of overhead + 992 bytes of data = 1024 transfer size. 1/4 the data = 1/4 the overhead. I rearranged my reading like so: resultz = is.read(cbuf,0,3968); resultz = is.read(cbuf,3968,3968); resultz = is.read(cbuf,7936,3968); while (!(is.ready())); // wait for ready resultz = is.read(cbuf,11904,3334); and this grabs 15,238 bytes total. BUT, I still have the quandry of the screwed up multi-bytes. I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. Approx 8% of the data. The bad bytes always seem to take the flavor of 0x2018, 0x2019, x2022, x2030, x201d. Are these maybe errors and I don't know what they enumerate to? I still can't believe some other layer isn't handling putting those bytes together all in one stream for me. Thanks Keith ----- Original Message ----- From: "Keith" To: "Bob Jacobsen" ; "RXTX Developers and Users" Sent: Saturday, March 03, 2007 11:26 AM Subject: Re: [Rxtx] is.read() only returning 3968 bytes > Bob, > > > Interesting numerical coincidence is that (max USB transfer) - (what > > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > > needed to transfer that much data. > > I was thinking along the same lines. I don't know USB well, but I do know > that those numbers were close enough to warrant investigating the > relationship between them. > > > I think what you're seeing is the internal buffering of the USB data > > stream. You'll need some form of higher-level buffering to smooth > > that out. > > Shouldn't the InputStreamReader() and BufferedReader() provide this type of > buffering? Isn't that the idea behind those? > > > All hypotheses need to be tested. In this case, a test would be to > > check for missing data. If this idea is right, you'll get _all_ the > > data, but you won't be missing characters. > > I did start looking at the data. -- I'm getting weird results. > > I tried this: > > loopzz = 0; > > for (looptwo = 0; looptwo < 100000; looptwo++) { > while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > > }} > > So I'm reading one character at a time. The good news is that loopzz is > exactly 15238 at the end of the routine, which is perfectly correct. I > picked looptwo value out of thin air. > > The weird results come in terms of the values, the data isn't correct at > least in one case. Look here: > > 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > > This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). > But the 0x89 was replaced by 0x2030. Why the heck would the returned value > be 0x2030?? Why is the returned byte completely out of range? Why the > multibyte return? > > From InputStream in the API: > > read > public abstract int read() > throws IOExceptionReads the next byte of data from the > input stream. The value byte is returned as an int in the range 0 to 255. If > no byte is available because the end of the stream has been reached, the > value -1 is returned. This method blocks until input data is available, the > end of the stream is detected, or an exception is thrown. > Value should be 0-255. > > > In my application time is really critical, reading 1 byte at a time is > probably not going to work. > > Thanks Eric & Bob for looking at this. > > Keith > From tjarvi at qbang.org Sat Mar 3 12:52:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 12:52:27 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > update: > > I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now > instead of 3968. > > This makes sense. > > 128 bytes of overhead + 3968 bytes of data = 4096 transfer size > 32 bytes of overhead + 992 bytes of data = 1024 transfer size. > > 1/4 the data = 1/4 the overhead. > > I rearranged my reading like so: > > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. > Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? > > I still can't believe some other layer isn't handling putting those bytes > together all in one stream for me. > The layer for this in Serial land is flow control. Software and hardware flow control prevent the overruns you observe. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:54:41 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:54:41 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <001a01c75dcd$c8802a70$6600a8c0@jbh757ktruws7g> Trent, Thanks for taking the time to reply. > I would expect a 20 meg application is going to have different behavior > with the OS than a smaller application with respect to the kernel memory > managment, schedualing, ... Something subtle could be causing problems. Well, at least I know the VCP drivers, the OS, etc can handle 2mbps reliably. Without hiccuping or dropping bytes. The C++ code works reliably without flow control. > The missing data is typical when not using flow control. When the OS > buffering fills, the hardware will start dropping bytes. I'm actually not getting MISSING data, I'm getting CORRUPTED data. If you look at my most recent post, I'm getting these bad bytes in place of the correct values: 0x2018, 0x2019, x2022, x2030, x201d. Why would is.read() return values not in the range of 0-255 ? Thanks. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 08:59:14 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 07:59:14 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: At 1:19 AM -0500 3/3/07, Keith wrote: >If I do a > >resultz = is.read(cbuf,0,15238); in java with RXTX > >where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > >and where resultz is an int, and cbuf is a char [] cbuf, resultz gets >EXACTLY 3968 bytes the first time called. If I call it multiple times, I get >roughly 11k total(less than what is sent), never more than the 3968 bytes >per is.read() call. > >My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 >bytes. Interesting numerical coincidence is that (max USB transfer) - (what you get) = 4096-3968 = 128 bytes is (almost) the size of the headers needed to transfer that much data. I think what you're seeing is the internal buffering of the USB data stream. You'll need some form of higher-level buffering to smooth that out. All hypotheses need to be tested. In this case, a test would be to check for missing data. If this idea is right, you'll get _all_ the data, but you won't be missing characters. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 09:26:14 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 11:26:14 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Bob, > Interesting numerical coincidence is that (max USB transfer) - (what > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > needed to transfer that much data. I was thinking along the same lines. I don't know USB well, but I do know that those numbers were close enough to warrant investigating the relationship between them. > I think what you're seeing is the internal buffering of the USB data > stream. You'll need some form of higher-level buffering to smooth > that out. Shouldn't the InputStreamReader() and BufferedReader() provide this type of buffering? Isn't that the idea behind those? > All hypotheses need to be tested. In this case, a test would be to > check for missing data. If this idea is right, you'll get _all_ the > data, but you won't be missing characters. I did start looking at the data. -- I'm getting weird results. I tried this: loopzz = 0; for (looptwo = 0; looptwo < 100000; looptwo++) { while (is.ready()) { cbuf[loopzz] = (char) is.read(); loopzz++; }} So I'm reading one character at a time. The good news is that loopzz is exactly 15238 at the end of the routine, which is perfectly correct. I picked looptwo value out of thin air. The weird results come in terms of the values, the data isn't correct at least in one case. Look here: 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). But the 0x89 was replaced by 0x2030. Why the heck would the returned value be 0x2030?? Why is the returned byte completely out of range? Why the multibyte return? >From InputStream in the API: read public abstract int read() throws IOExceptionReads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown. Value should be 0-255. In my application time is really critical, reading 1 byte at a time is probably not going to work. Thanks Eric & Bob for looking at this. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 14:44:50 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 13:44:50 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: Java's "char" type is Unicode. I think what you're seeing is a bug in the byte -> Unicode translation. 0x2018, 0x2019 are the curly open and close quotes. There used to be (and might still be) bugs in the conversion of these in a couple of libc versions. Some of the ASCII -> ISO and ISO -> ASCII routines were a little over-ambitious with respect to handling the open and close quotes, and tried to convert them to the "curly" form inappropriately. Try _not_ casting it to char. Bob At 11:26 AM -0500 3/3/07, Keith wrote: >Bob, > >> Interesting numerical coincidence is that (max USB transfer) - (what >> you get) = 4096-3968 = 128 bytes is (almost) the size of the headers >> needed to transfer that much data. > >I was thinking along the same lines. I don't know USB well, but I do know >that those numbers were close enough to warrant investigating the >relationship between them. > >> I think what you're seeing is the internal buffering of the USB data >> stream. You'll need some form of higher-level buffering to smooth >> that out. > >Shouldn't the InputStreamReader() and BufferedReader() provide this type of >buffering? Isn't that the idea behind those? > >> All hypotheses need to be tested. In this case, a test would be to >> check for missing data. If this idea is right, you'll get _all_ the >> data, but you won't be missing characters. > >I did start looking at the data. -- I'm getting weird results. > >I tried this: > >loopzz = 0; > >for (looptwo = 0; looptwo < 100000; looptwo++) { >while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > >}} > >So I'm reading one character at a time. The good news is that loopzz is >exactly 15238 at the end of the routine, which is perfectly correct. I >picked looptwo value out of thin air. > >The weird results come in terms of the values, the data isn't correct at >least in one case. Look here: > >0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > >This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). >But the 0x89 was replaced by 0x2030. Why the heck would the returned value >be 0x2030?? Why is the returned byte completely out of range? Why the >multibyte return? > >>From InputStream in the API: > >read >public abstract int read() > throws IOExceptionReads the next byte of data from the >input stream. The value byte is returned as an int in the range 0 to 255. If >no byte is available because the end of the stream has been reached, the >value -1 is returned. This method blocks until input data is available, the >end of the stream is detected, or an exception is thrown. >Value should be 0-255. > > >In my application time is really critical, reading 1 byte at a time is >probably not going to work. > >Thanks Eric & Bob for looking at this. > >Keith > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 15:10:11 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 17:10:11 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Bob said ..... > Java's "char" type is Unicode. I think what you're seeing is a bug > in the byte -> Unicode translation. Bob -- I think you hit the nail on the head. I was just coming to the same realization here. I knew that something funny was going on because the same bytes always got "corrupted." I'm pretty sure its in the InputStreamReader() functionality where the conversion junk is happening. Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. I don't know if simply changing the cast is going to work. Since the conversion is happening upstream (pun intended), I don't think my cast is doing this. Also I think the compiler forced me to use the cast. I'm still playing around, and I'll report back once I nail it down. Thanks!! Keith From tjarvi at qbang.org Sat Mar 3 15:59:46 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 15:59:46 -0700 (MST) Subject: [Rxtx] Win64 rxtx Testers? Message-ID: I have compiled win64 binaries of rxtx. Are there any users interested in testing them? If so, I'll look into putting them on the web site. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Mar 3 15:35:06 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 14:35:06 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: Because of this and similar problems, JMRI does all it's serial IO using +only+ byte values. It's a but of a pain, as Java wants to go to char and int types a little too aggressively, but it does solve the "uncontrolled conversions" problems. Bob At 5:10 PM -0500 3/3/07, Keith wrote: >Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > >Bob -- I think you hit the nail on the head. > >I was just coming to the same realization here. I knew that something funny >was going on because the same bytes always got "corrupted." > >I'm pretty sure its in the InputStreamReader() functionality where the >conversion junk is happening. > >Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > >I don't know if simply changing the cast is going to work. Since the >conversion is happening upstream (pun intended), I don't think my cast is >doing this. Also I think the compiler forced me to use the cast. -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mark at mdsh.com Sun Mar 4 11:01:33 2007 From: mark at mdsh.com (Mark Himsley) Date: Sun, 04 Mar 2007 18:01:33 +0000 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: <5C01AC72C200388815C04982@bedroom.mdsh.local> On 03 March 2007 14:38 -0500 Keith wrote: > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT > consistent. Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? It looks like you need to use DataInputStream and DataOutputStream. -- Mark Himsley From tjarvi at qbang.org Sun Mar 4 11:35:08 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 11:35:08 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" > > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > > * Line #21 - Not sure if you need a (TM) mark for > the term "Sun" > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > OK. I'm going through this today. Some groups ask if rxtx could be under their license also. I think this is a good example of why I resist multiple licenses and focus on why the current license may not be usable by them. The RXTX project is a convergence of hobby and commercial interests. I happen to do both right now. The problem with licensing is we have to stay on top of them as they change. Clearly, adding more licenses will not make this easier. I'm acting as the hobby person today. RXTX always favors the hobby people. But as we move forward, I'm going to need to bring this to lawyers at work and explain to them what is going on. Others here may have to do this also. I don't anticipate problems or unexpected changes. The goal is a consistant, comprehendable and usable license as close to what we have now as possible. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 14:52:10 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 14:52:10 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (1/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: I'm breaking this into two parts. I expect the second part will need more attention. Comments first, then the changed material below. On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > Thanks > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. OK. RXTX for consitent use. java should not be capitalized because it does not only mean Sun [TM] Java [TM]. An example of this not meaning Java is when people use RXTX with GCJ. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". There are not any contributors that are in all of RXTX yet but I did update the comment to try to reflect the current situation without making it a nightmare to maintain. I looked to see how the Linux kernel does it as a reference point. > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" The URL can be problematic. I have done so below with a time reference. GNU does not provide version information in their URLS. I picture this being a problem when the version 3 comes out. > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > This will be corrected when the copy is updated to the version linked below. ---------------- begin proposed material involved -------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. ----------------- end proposed material involved -------------------- I'll be looking at the linking issue again next. That should be all that remains other than including the 2.1 version. Let me know if you have problems with anything here. I do not want to dilute the material I post next with these housekeeping tasks. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 16:08:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 16:08:36 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: For those that are wondering what is going on here, this next bit is the meat of the changes. We agreed a long time ago to put this disclaimer in. We did a so so job. It was in rxtx 2.0, not well written, ... So some groups using rxtx that would like to ship rxtx so users don't need to download, install, go to the mail-list to find why it failed, ... Then their legal teams tell them section 5 paragraph 2 is a show stopper. That was never the intent. Now going through what remains... > and might need a (TM) suffix to make Sun happy. Added disclaimer at the ended 'all trademarks belong...' > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. OK. As you can see I was trying to adjust GNU text there for the LGPL. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. used dynamically linked terminology. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". I tried to address this more upfront with an intent statement. Let me know if you have problems with it. I also tried to make it a little more clear what was derived from the GNU solution by moving the link location closer to GNU's suggestion. > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > Thats the intent. Here is the combined fixes. Note that only the material in /*-- --*/ is being touched. The new GPL license is there but unmodified. ------------------------ begin proposed new license ------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. | | An executable that contains no derivative of any portion of RXTX, but | is designed to work with RXTX by being dynamically linked with it, | is considered a "work that uses the Library" subject to the terms and | conditions of the GNU Lesser General Public License. | | The following has been added to the RXTX License to remove | any confusion about linking to RXTX. We want to allow in part what | section 5, paragraph 2 of the LGPL does not permit in the special | case of linking over a controlled interface. The intent is to add a | Java Specification Request or standards body defined interface in the | future as another exception but one is not currently available. | | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface | | As a special exception, the copyright holders of RXTX give you | permission to link RXTX with independent modules that communicate with | RXTX solely through the Sun Microsytems CommAPI interface version 2, | regardless of the license terms of these independent modules, and to copy | and distribute the resulting combined work under terms of your choice, | provided that every copy of the combined work is accompanied by a complete | copy of the source code of RXTX (the version of RXTX used to produce the | combined work), being distributed under the terms of the GNU Lesser General | Public License plus this exception. An independent module is a | module which is not derived from or based on RXTX. | | Note that people who make modified versions of RXTX are not obligated | to grant this special exception for their modified versions; it is | their choice whether to do so. The GNU Lesser General Public License | gives permission to release a modified version without this exception; this | exception also makes it possible to release a modified version which | carries forward this exception. | | You should have received a copy of the GNU Lesser General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA | All trademarks belong to their respective owners. --------------------------------------------------------------------------*/ The original GNU Lesser General Public License Follows. GNU LESSER GENERAL PUBLIC LICENSE Version 2.1, February 1999 Copyright (C) 1991, 1999 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. [This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence the version number 2.1.] Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This license, the Lesser General Public License, applies to some specially designated software packages--typically libraries--of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below. When we speak of free software, we are referring to freedom of use, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish); that you receive source code or can get it if you want it; that you can change the software and use pieces of it in new free programs; and that you are informed that you can do these things. To protect your rights, we need to make restrictions that forbid distributors to deny you these rights or to ask you to surrender these rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library or if you modify it. For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights. We protect your rights with a two-step method: (1) we copyright the library, and (2) we offer you this license, which gives you legal permission to copy, distribute and/or modify the library. To protect each distributor, we want to make it very clear that there is no warranty for the free library. Also, if the library is modified by someone else and passed on, the recipients should know that what they have is not the original version, so that the original author's reputation will not be affected by problems that might be introduced by others. Finally, software patents pose a constant threat to the existence of any free program. We wish to make sure that a company cannot effectively restrict the users of a free program by obtaining a restrictive license from a patent holder. Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license. Most GNU software, including some libraries, is covered by the ordinary GNU General Public License. This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs. When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library. We call this license the "Lesser" General Public License because it does Less to protect the user's freedom than the ordinary General Public License. It also provides other free software developers Less of an advantage over competing non-free programs. These disadvantages are the reason we use the ordinary General Public License for many libraries. However, the Lesser license provides advantages in certain special circumstances. For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License. In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software. For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU operating system, as well as its variant, the GNU/Linux operating system. Although the Lesser General Public License is Less protective of the users' freedom, it does ensure that the user of a program that is linked with the Library has the freedom and the wherewithal to run that program using a modified version of the Library. The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, whereas the latter must be combined with the library in order to run. GNU LESSER GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License Agreement applies to any software library or other program which contains a notice placed by the copyright holder or other authorized party saying it may be distributed under the terms of this Lesser General Public License (also called "this License"). Each licensee is addressed as "you". A "library" means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables. The "Library", below, refers to any such software library or work which has been distributed under these terms. A "work based on the Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term "modification".) "Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library. Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does. 1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) The modified work must itself be a software library. b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change. c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License. d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful. (For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library. In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. 4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange. If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code. 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables. When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law. If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.) Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself. 6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications. You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things: a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.) b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. c) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution. d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place. e) Verify that the user has already received a copy of these materials or that you have already sent this user a copy. For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute. 7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things: a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above. b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work. 8. You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 9. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Library (or any work based on the Library), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Library or works based on it. 10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties with this License. 11. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply, and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 12. If the distribution and/or use of the Library is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Library under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 13. The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation. 14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Libraries If you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the ordinary General Public License). To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Also add information on how to contact you by electronic and paper mail. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the library, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the library `Frob' (a library for tweaking knobs) written by James Random Hacker. , 1 April 1990 Ty Coon, President of Vice That's all there is to it! ------------------------ end of proposed license ------------------ -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sun Mar 4 16:26:04 2007 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 04 Mar 2007 17:26:04 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <45EB558C.3010609@cox.net> Bob Jacobsen wrote: > Because of this and similar problems, JMRI does all it's serial IO > using +only+ byte values. It's a but of a pain, as Java wants to go > to char and int types a little too aggressively, but it does solve > the "uncontrolled conversions" problems. Anytime that you are reading bytes of data that is not printable, unicode text, in Java, you really need to stay away from the Readers. Use input stream only, or you will see unicode valued byte groups converted to unicode "char" values. Gregg Wonderly From joachim at buechse.de Mon Mar 5 04:23:48 2007 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 5 Mar 2007 12:23:48 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> The behaviour is exactly what you asked for in you code. is = new BufferedReader(new InputStreamReader(port.getInputStream())); Readers return Text (ie unicode chars) not bytes. You instantiate the InputStreamReader without saying which charset you want, which means "platform default". As this is on Windows, it will convert Windows characters to equivalent unicode characters. If you want to read bytes, read bytes not Text. Reading bytes is done with InputStream and BufferedInputStream. BTW: The InputStream and Reader methods that read arrays are not guarenteed to fill up the array. You always have to check what you really got, and advance your index accordingly. A typical "read up to 32k" method looks like this: InputStream is= ... // -- determine the max buffer size int len= is.available(); if (len == 0) { len= 32 * 1024; } // -- read all available data byte[] buffer= new byte[len]; int pos= 0; int read; do { read= is.read(buffer, pos, buffer.length - pos); pos= pos + read; } while (read != -1 && pos < buffer.length); Best regards, Joachim --- Joachim B?chse Phone: +41 44 500 2604 Buechse Consulting Hadlaubsteig 2 CH-8006 Z?rich On 03.03.2007, at 23:10, Keith wrote: > Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > > Bob -- I think you hit the nail on the head. > > I was just coming to the same realization here. I knew that > something funny > was going on because the same bytes always got "corrupted." > > I'm pretty sure its in the InputStreamReader() functionality where the > conversion junk is happening. > > Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > > I don't know if simply changing the cast is going to work. Since the > conversion is happening upstream (pun intended), I don't think my > cast is > doing this. Also I think the compiler forced me to use the cast. > > I'm still playing around, and I'll report back once I nail it down. > > Thanks!! > > Keith > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Mon Mar 5 07:25:46 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 05 Mar 2007 08:25:46 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> Message-ID: <45EC286A.8060608@cox.net> Joachim Buechse wrote: > BTW: The InputStream and Reader methods that read arrays are not > guarenteed to fill up the array. You always have to check what you > really got, and advance your index accordingly. A typical "read up to > 32k" method looks like this: > > InputStream is= ... > // -- determine the max buffer size > int len= is.available(); > if (len == 0) { > len= 32 * 1024; > } > // -- read all available data > byte[] buffer= new byte[len]; > int pos= 0; > int read; > do { > read= is.read(buffer, pos, buffer.length - pos); > pos= pos + read; > } while (read != -1 && pos < buffer.length); > My preferred structure is. byte arr[ len ]; int cnt; int off = 0; while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { off += cnt; } This keeps you from adding -1 to pos when the read returns -1. It also skips out when the read is 0 bytes which, is not a described EOF in InputStream java docs, but is a condition I want to be aware of. Gregg Wonderly From joachim at buechse.de Tue Mar 6 02:52:58 2007 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 6 Mar 2007 10:52:58 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <45EC286A.8060608@cox.net> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: The code I copied was from a file resource reader, it shouldn't really be applied to networking/external IO code. Mea culpa. However aborting when you get 0 from read is not always what you want either (you kind of indicated that already). Some unix java implementations will return 0 if the kernel read was aborted with EINTER, which is rarely the point where you want to abort your read - at least not without further checks. A "complete" solution always depends on the events you need to handle and the time the total read could take in reality. In some cases it's worth checking Thread.isInterrupted() in the loop, some code re-loops on 0 but only a limited number of times, some check a total timeout limit, etc... Best regards, Joachim On 05.03.2007, at 15:25, Gregg Wonderly wrote: > My preferred structure is. > > byte arr[ len ]; > int cnt; > int off = 0; > while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { > off += cnt; > } > > This keeps you from adding -1 to pos when the read returns -1. It > also skips > out when the read is 0 bytes which, is not a described EOF in > InputStream java > docs, but is a condition I want to be aware of. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Mar 6 14:47:44 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 Mar 2007 14:47:44 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: Just FYI, rxtx will usually not break out on EINTER. The code in the native library usually does something close to this: do { read(...) } while ( !done && errno==EINTR ); Obviously there is a little more involved but it will retry on EINTER if not done. On Tue, 6 Mar 2007, Joachim Buechse wrote: > The code I copied was from a file resource reader, it shouldn't > really be applied to networking/external IO code. Mea culpa. > > However aborting when you get 0 from read is not always what you want > either (you kind of indicated that already). Some unix java > implementations will return 0 if the kernel read was aborted with > EINTER, which is rarely the point where you want to abort your read - > at least not without further checks. A "complete" solution always > depends on the events you need to handle and the time the total read > could take in reality. In some cases it's worth checking > Thread.isInterrupted() in the loop, some code re-loops on 0 but only > a limited number of times, some check a total timeout limit, etc... > > Best regards, > Joachim > > On 05.03.2007, at 15:25, Gregg Wonderly wrote: >> My preferred structure is. >> >> byte arr[ len ]; >> int cnt; >> int off = 0; >> while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { >> off += cnt; >> } >> >> This keeps you from adding -1 to pos when the read returns -1. It >> also skips >> out when the read is 0 bytes which, is not a described EOF in >> InputStream java >> docs, but is a condition I want to be aware of. >> >> Gregg Wonderly >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 gjhanna at gmail.com Thu Mar 8 13:42:52 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Fri, 9 Mar 2007 09:42:52 +1300 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? Message-ID: I've just struck an issue using rxtx in a multi-threaded environment: If I have 3 threads trying to open *the same* comm-port I get a deadlock in CommPortIdentifier.open If I have just 2, it works fine - I get a PortInUseException which is nice and I can handle it. The 3 thread->deadlock thing is causing me issues. (Sample code below). This is from the java thread-dump Found one Java-level deadlock: ============================= "Thread-2": waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object ), which is held by "Thread-1" "Thread-1": waiting to lock monitor 0x0003e9cc (object 0x2450e108, a gnu.io.CommPortIdentifier), which is held by "Thread-2" Java stack information for the threads listed above: =================================================== "Thread-2": at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:329) - waiting to lock <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) "Thread-1": at java.lang.Object.wait(Native Method) - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) - locked <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) (Apart from this, rxtx is working fantastically for us). I'm thinking I'll have to implement some sort of locking mechanism that *doesn't* use java synchronization to prevent this situation. (Which doesn't sound like a good idea to me). Any ideas? Thanks, Greg Hanna ============= RXTXLockTest.java ======================================== import gnu.io.CommPort; import gnu.io.CommPortIdentifier; /** * @author Greg Hanna * Minimal code to create a deadlock with rxtx in multithreaded open */ public class RXTXLockTest { public static void main(String[] args) { try { CommPortIdentifier cpiCom1 = CommPortIdentifier.getPortIdentifier ("COM14"); OpenThread t1 = new OpenThread (" one ", cpiCom1); OpenThread t2 = new OpenThread (" two ", cpiCom1); OpenThread t3 = new OpenThread (" 003 ", cpiCom1); t1.start(); t2.start(); t3.start(); // comment this out and it runs with (expected) PortInUseException } catch (Exception e) { e.printStackTrace(); } } } class OpenThread extends Thread { String name; CommPortIdentifier cpi; CommPort cp; public OpenThread (String name, CommPortIdentifier cpi) { this.name = name; this.cpi = cpi; System.out.println (System.currentTimeMillis() + name + " thread created"); } public void run () { try { System.out.println (System.currentTimeMillis() + name + " opening"); cp = cpi.open(name, 2000); System.out.println (System.currentTimeMillis() + name + " opened - sleeping"); sleep (2000); // do the serial comms with the device. System.out.println (System.currentTimeMillis() + name + " slept - closing"); cp.close(); System.out.println (System.currentTimeMillis() + name + " closed - exiting"); } catch (Exception e) { System.out.println ("Error in thread: " + name ); e.printStackTrace(); } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070308/d9a163c5/attachment-0001.html From eu259473 at tele2.it Fri Mar 9 02:46:20 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 09 Mar 2007 10:46:20 +0100 Subject: [Rxtx] rxtx: tru64 unix make fails Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070309/3b654523/attachment-0001.html From lyon at docjava.com Fri Mar 9 03:58:32 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 Mar 2007 05:58:32 -0500 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi All, The deadlock issue is one that I have been thinking about for some time now. It seems to me that we need a resource manager that enables assignment to a known process. The one thing that seems important about serial ports is that two applications should not use the same serial port at the same time. When this happens, it throws an exception. OK. The exception is a response to a lock condition that arises from an unavailable resource. An abstract implementation (not born of native methods) might assign a serial port to an application, until the application releases it (or is forced to release it by some kill mechanism). Some resources (like a registry) can be reused. But others, like the serial port, cannot. In the case of the serial port, we would like, I think, to have the flyweight design pattern without sharing and with object assignment tracking. A means of breaking deadlock (like a leasing mechanism) seems very useful, to me. My guess is that we can serialize the state of the Parametric Singleton Pattern (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) into the Preferences of the System. Preferences.systemRoot() might help with that. When a resource is checked out, the lease time and owner are listed. A thread that does this can be killed, but applications outside of Java are problematic. There is a compelling problem here. It is not just serial ports. Sound cards, cameras, microphones, files, tape drives, etc. All are consumed resources that are assigned to an application (or user) and deprive other applications, or users, from use. What, if anything, should we do? At present we throw PortInUseExceptions. Is that it? Can we do better? OK, the port is in use. Now what? Do I have to be root to go remove lock files and kill applications? Is there a better way? Thanks! - Doug >I've just struck an issue using rxtx in a multi-threaded environment: > >If I have 3 threads trying to open *the same* >comm-port I get a deadlock in >CommPortIdentifier.open >If I have just 2, it works fine - I get a >PortInUseException which is nice and I can >handle it. > >The 3 thread->deadlock thing is causing me issues. >(Sample code below). > >This is from the java thread-dump > >Found one Java-level deadlock: >============================= >"Thread-2": > waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), > which is held by "Thread-1" >"Thread-1": > waiting to lock monitor 0x0003e9cc (object >0x2450e108, a gnu.io.CommPortIdentifier ), > which is held by "Thread-2" > >Java stack information for the threads listed above: >=================================================== >"Thread-2": > at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) > - waiting to lock <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) >"Thread-1": > at java.lang.Object.wait(Native Method) > - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) > - locked <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) > > >(Apart from this, rxtx is working fantastically for us). > >I'm thinking I'll have to implement some sort of >locking mechanism that *doesn't* use java >synchronization to prevent this situation. >(Which doesn't sound like a good idea to me). > >Any ideas? > >Thanks, > >Greg Hanna > >============= RXTXLockTest.java ======================================== > >import gnu.io.CommPort; >import gnu.io.CommPortIdentifier; > >/** > * @author Greg Hanna > * Minimal code to create a deadlock with rxtx in multithreaded open > */ >public class RXTXLockTest { > ? > ?public static void main(String[] args) { > ?try { > ?CommPortIdentifier cpiCom1 = >CommPortIdentifier.getPortIdentifier ("COM14"); > ?OpenThread t1 = new OpenThread (" one ", cpiCom1); > ?OpenThread t2 = new OpenThread (" two ", cpiCom1); > ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); > ?t1.start(); > ?t2.start(); > ?t3.start(); // comment this out >and it runs with (expected) PortInUseException > ?} catch (Exception e) { > ?e.printStackTrace(); > ?} > ?} >} > >class OpenThread extends Thread { > ?String name; > ?CommPortIdentifier cpi; > ?CommPort cp; > ?public OpenThread (String name, CommPortIdentifier cpi) { > ? this.name = name; > ?this.cpi = cpi; > ?System.out.println >(System.currentTimeMillis() + name + " thread >created"); > ?} > ?public void run () { > ?try { > ?System.out.println >(System.currentTimeMillis() + name + " opening"); > ?cp = cpi.open(name, 2000); > ?System.out.println >(System.currentTimeMillis() + name + " opened - >sleeping"); > ?sleep (2000); // do the serial comms with the device. > ?System.out.println >(System.currentTimeMillis() + name + " slept - >closing"); > ?cp.close(); > ?System.out.println >(System.currentTimeMillis() + name + " closed - >exiting"); > ?} catch (Exception e) { > System.out.println ("Error in thread: " + name ); > ?e.printStackTrace(); > ?} > ?} >} > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Mar 9 06:37:45 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 Mar 2007 06:37:45 -0700 (MST) Subject: [Rxtx] rxtx: tru64 unix make fails In-Reply-To: References: Message-ID: On Fri, 9 Mar 2007, "Giuseppe Marchese" wrote: > Sorry for delay. > ? > This is log for ./configure and make > error. > ? > thanks for attention > ? > Make: '%.java,$(TOP)/$(CLASSDEST)/%.class,$(wildcard $(SPATH)/*.java)': extra chars.? > Stop. > Hi Giuseppe You need to use GNU make with the Makefile. I suspect the tru64 make is not happy with those rules. > configure: exit 0 Looks like configure is fairly happy. From tjarvi at qbang.org Sat Mar 10 07:43:51 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 07:43:51 -0700 (MST) Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi Doug I have very little time to look into this further but what we could do is open up an rxtx 3 devel branch in which a proof of concept could be worked on. It could be the proof of concept for a JSR others including Sun could look at/work on or parts of it could be recycled in a JSR. I'm working very hard on rxtx right now but it does not show. I'm looking at win64, mac intel/ppc, usb bluetooth and usb serial dongles. Some are going to be more tested than others but they are all on the plate. I'll be pushing all the fixes upstream when they are done. So I'm very busy in 2.1 but we could open a new branch. On Fri, 9 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > The deadlock issue is one that I have been thinking about > for some time now. > It seems to me that we need a resource manager that enables assignment > to a known process. > > The one thing that seems important about serial > ports is that two applications should not use the > same serial port at the same time. When this > happens, it throws an exception. > OK. > > The exception is a response to a lock condition that > arises from an unavailable resource. > > An abstract implementation (not born of native methods) might > assign a serial port to an application, until the > application releases it (or is forced to release > it by some kill mechanism). > > Some resources (like a registry) can be reused. > But others, like the serial port, > cannot. > > In the case of the serial port, we would like, I think, to > have the flyweight design pattern > without sharing and with object assignment tracking. > A means of breaking deadlock (like a leasing > mechanism) seems very useful, to me. > > My guess is that we can serialize the state of the Parametric Singleton Pattern > (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) > into the Preferences of the System. Preferences.systemRoot() might help > with that. When a resource is checked out, the lease time and owner are > listed. A thread that does this can be killed, but applications outside of Java > are problematic. > > There is a compelling problem here. It is not just serial ports. > Sound cards, cameras, microphones, files, tape drives, etc. All are consumed > resources that are assigned to an application (or > user) and deprive other applications, > or users, from use. > > What, if anything, should we do? At present we throw PortInUseExceptions. > Is that it? > Can we do better? > OK, the port is in use. Now what? > Do I have to be root to go remove lock files and kill applications? > Is there a better way? > > Thanks! > - Doug > >> I've just struck an issue using rxtx in a multi-threaded environment: >> >> If I have 3 threads trying to open *the same* >> comm-port I get a deadlock in >> CommPortIdentifier.open >> If I have just 2, it works fine - I get a >> PortInUseException which is nice and I can >> handle it. >> >> The 3 thread->deadlock thing is causing me issues. >> (Sample code below). >> >> This is from the java thread-dump >> >> Found one Java-level deadlock: >> ============================= >> "Thread-2": >> waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), >> which is held by "Thread-1" >> "Thread-1": >> waiting to lock monitor 0x0003e9cc (object >> 0x2450e108, a gnu.io.CommPortIdentifier ), >> which is held by "Thread-2" >> >> Java stack information for the threads listed above: >> =================================================== >> "Thread-2": >> at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) >> - waiting to lock <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> "Thread-1": >> at java.lang.Object.wait(Native Method) >> - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) >> - locked <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> >> >> (Apart from this, rxtx is working fantastically for us). >> >> I'm thinking I'll have to implement some sort of >> locking mechanism that *doesn't* use java >> synchronization to prevent this situation. >> (Which doesn't sound like a good idea to me). >> >> Any ideas? >> >> Thanks, >> >> Greg Hanna >> >> ============= RXTXLockTest.java ======================================== >> >> import gnu.io.CommPort; >> import gnu.io.CommPortIdentifier; >> >> /** >> * @author Greg Hanna >> * Minimal code to create a deadlock with rxtx in multithreaded open >> */ >> public class RXTXLockTest { >> ? >> ?public static void main(String[] args) { >> ?try { >> ?CommPortIdentifier cpiCom1 = >> CommPortIdentifier.getPortIdentifier ("COM14"); >> ?OpenThread t1 = new OpenThread (" one ", cpiCom1); >> ?OpenThread t2 = new OpenThread (" two ", cpiCom1); >> ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); >> ?t1.start(); >> ?t2.start(); >> ?t3.start(); // comment this out >> and it runs with (expected) PortInUseException >> ?} catch (Exception e) { >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> class OpenThread extends Thread { >> ?String name; >> ?CommPortIdentifier cpi; >> ?CommPort cp; >> ?public OpenThread (String name, CommPortIdentifier cpi) { >> ? this.name = name; >> ?this.cpi = cpi; >> ?System.out.println >> (System.currentTimeMillis() + name + " thread >> created"); >> ?} >> ?public void run () { >> ?try { >> ?System.out.println >> (System.currentTimeMillis() + name + " opening"); >> ?cp = cpi.open(name, 2000); >> ?System.out.println >> (System.currentTimeMillis() + name + " opened - >> sleeping"); >> ?sleep (2000); // do the serial comms with the device. >> ?System.out.println >> (System.currentTimeMillis() + name + " slept - >> closing"); >> ?cp.close(); >> ?System.out.println >> (System.currentTimeMillis() + name + " closed - >> exiting"); >> ?} catch (Exception e) { >> System.out.println ("Error in thread: " + name ); >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 mm at UDel.Edu Sat Mar 10 14:48:32 2007 From: mm at UDel.Edu (Mike Markowski) Date: Sat, 10 Mar 2007 16:48:32 -0500 Subject: [Rxtx] rxtx and Sun's comm api Message-ID: <45F327B0.2060004@udel.edu> Hi all, I joined the list a few days ago and apologize for what is likely a frequently asked question, though I haven't yet found it anywhere. I learned about rxtx.org through the readme on Sun's version 2 of their comms api. They give recommendations in that readme regarding how a better comms api should be written. Is this the aim of rxtx.org? I wrote an app on my linux box using the Sun comms api (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the fact that only linux and Solaris are supported. So I'm glad to find rxtx.org and am just reading up on how make the conversion so Windows users will be able to run the program as well. At the same time I'm just curious if rxtx.org and Sun are both heading in the same direction. Thanks for any background or historical info. Feel free to point me to any www pages if my googling has just completely missed the target! Thanks again, Mike From tjarvi at qbang.org Sat Mar 10 15:35:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 15:35:25 -0700 (MST) Subject: [Rxtx] rxtx and Sun's comm api In-Reply-To: <45F327B0.2060004@udel.edu> References: <45F327B0.2060004@udel.edu> Message-ID: On Sat, 10 Mar 2007, Mike Markowski wrote: > Hi all, > > I joined the list a few days ago and apologize for what is likely a > frequently asked question, though I haven't yet found it anywhere. I > learned about rxtx.org through the readme on Sun's version 2 of their > comms api. They give recommendations in that readme regarding how a > better comms api should be written. Is this the aim of rxtx.org? > > I wrote an app on my linux box using the Sun comms api > (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the > fact that only linux and Solaris are supported. So I'm glad to find > rxtx.org and am just reading up on how make the conversion so Windows > users will be able to run the program as well. At the same time I'm > just curious if rxtx.org and Sun are both heading in the same direction. > > Thanks for any background or historical info. Feel free to point me to > any www pages if my googling has just completely missed the target! > I do not have any news (good or bad) concerning RXTX and Sun working together but perhaps others here do. The main goal of RXTX is to expose POSIX termios interfaces to java users. The future support of javax.comm is questionable. We do not have resources for everything. gnu.io (RXTX 2.1) will be supported going forward and functions the same as CommAPI 2.0. If you have control of the source code you are working with, I would not advise using CommAPI 2.0 javax.comm. We do support CommAPI 2.0 javax.comm for older applications but I do not think that will last much longer for practical reasons. The download interest in CommAPI 2.0 javax.comm support is becomming negligible on this end. There has been discussion of a JSR effort but I do not know of any status change since it was mentioned. One problem with a JSR is that even a light weight process is going to be difficult for RXTX at this time. Maybe that will change in the future but then again it may not. For now, we are just going forward 'as is' in rxtx 2.1 with package gnu.io while trying as a secondary effort to backport the changes to rxtx 2.0 for javax.comm support for users that do not have a choice. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Mar 11 07:19:40 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 11 Mar 2007 08:19:40 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: Hi All, I have been a proponent of a JSR that makes use of RXTX. I have executed the proper agreements with Sun. At this point we are in the: Early Draft Review of Draft Specifications Stage. The best thing to do is to enter the quiet period and create a specification. The question of exactly how we, as a group, want to approach this problem, remains open. Typically, we should have both a specification and a reference implementation. Thus, it would be to our best advantage to have a nice, stable, cross platform RXTX distro that adheres to the groups specification. Now, from a specification standpoint, my personal view on the matter is that we create a series of interfaces, with nice documentation (or at least javadoc). Is this a good idea? Should we have a pure interface specification for the communication API? There are several issues, in my mind, which still weigh on us. Hot-pluggable dongles, long discovery process on pop-up ports, lack of uniformity on device names, lack of uniformity on locking, a precise understanding of how the SerialPortResourceManager works (or even if we should have one). The more questions we answer in our reference implementation, the better our specification will get. RXTX is a good working prototype, but, I don't know if that is what we want to use for a specification. Here is what I have for a CommPortInterface: */ public interface CommPortInterface { /** * @return a string representation of this port. */ String toString(); /** * Gets the name of the communications port. This name should correspond to * something the user can identify, like the label on the hardware. * @return name of the port */ String getName(); /** * @return an input stream that can be used to read data from the * communications port. If the port doesn't support reading data, this * method returns null. *

* The blocking behaviour of this input stream depends on the threshold * and timeout values, as shown below for a read buffer size of n * bytes: * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ThresholdTimeoutBlocking behaviour
StateValueStateValue
disableddisabledblock until data is available
enabledm bytesdisabledblock until min(m, n) bytes are available
disabledenabledt msblock for t ms or until data is available
enabledm bytesenabledt msblock for t ms or until min(m, n) bytes are * available
* @throws java.io.IOException */ InputStream getInputStream() throws IOException; /** * @return an output stream that can be used to send data to the * communications port. If the port doesn't support sending data, this * method returns null. * @throws java.io.IOException */ OutputStream getOutputStream() throws IOException; /** * Closes this communications port. * All PortOwnershipListeners will be? * notified of this change of ownership. Further method calls on this? * object will throw IllegalStateException. Further calls on the? * associated InputStream or OutputStream will throw IOException. *

* Close does not block. Undelivered data is discarded. Blocked read and? * write operations are aborted if the underlying operating systems? * supports an IO abort mechanism. To await the delivery of undelivered? * data call OutputStream.flush() or OutputStream.close() before calling? * Port.close(). */ void close(); /** * Enables receive threshold. * When the specified threshold number of bytes are retrieved, read will * return immediately. * * @param thresh the number of bytes in the input buffer * @throws gnu.io.UnsupportedCommOperationException * if receive threshold is * not supported by the driver * @see #disableReceiveThreshold */ void enableReceiveThreshold(int thresh) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive threshold. * * @see #enableReceiveThreshold */ void disableReceiveThreshold(); /** * @return true if receive threshold is enabled. * * @see #enableReceiveThreshold */ boolean isReceiveThresholdEnabled(); /** * @return the receive threshold value. If receive threshold is diabled * or not supported, this value is meaningless. * * @see #enableReceiveThreshold */ int getReceiveThreshold(); /** * Enables receive timeout. * When the specified number of milliseconds have elapsed, read will * return immediately. * * @param rcvTimeout the number of milliseconds to block for * @throws gnu.io.UnsupportedCommOperationException * if receive timeout is * not supported by the driver * @see #disableReceiveTimeout */ void enableReceiveTimeout(int rcvTimeout) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive timeout. * * @see #enableReceiveTimeout */ void disableReceiveTimeout(); /** * @return true if receive timeout is enabled. * * @see #enableReceiveTimeout */ boolean isReceiveTimeoutEnabled(); /** * @return the receive timeout value. If receive timeout is diabled * or not supported, this value is meaningless. * * @see #enableReceiveTimeout */ int getReceiveTimeout(); /** * Enables receive framing. * The supplied byte value in the input suggests the end of the received * frame, and read returns immediately. Only the low 8 bits of the * supplied value are significant. * * @param framingByte the frame delimiter * @throws gnu.io.UnsupportedCommOperationException * if receive framing is * not supported by the driver * @see #disableReceiveFraming */ void enableReceiveFraming(int framingByte) throws UnsupportedCommOperationException; /** * Disables receive framing. * * @see #enableReceiveFraming */ void disableReceiveFraming(); /** * @return true if receive framing is enabled. * * @see #enableReceiveFraming */ boolean isReceiveFramingEnabled(); /** * @return true if receive framing byte. If receive framing is diabled * or not supported, this value is meaningless. * * @see #enableReceiveFraming */ int getReceiveFramingByte(); /** * Sets the input buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setInputBufferSize(int size); /** * @return the input buffer size. * The driver may choose not to report correct values. */ int getInputBufferSize(); /** * Sets the output buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setOutputBufferSize(int size); /** * @return the output buffer size. * The driver may choose not to report correct values. */ int getOutputBufferSize(); } What do you think of that? Note the wishy washy nature of the spec: The driver may choose to ignore this method. Is that good enough for us? Thanks! - Doug From ra85551 at gmail.com Sun Mar 11 08:44:45 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Sun, 11 Mar 2007 17:44:45 +0300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hello, world! I am writing application that communicates with modem via AT commands. My OS is Linux Kubuntu Feisty Herd, to ensure that my application will run properly under Windows XP I installed VMWare server. When I tried to send AT command and evaluate modem answer under WinXP @ VMWare server, I actually didn't receive anything. I think that VM settings are right, because I do can communicate with modem by using standard HyperTerminall as well as I can do on native Windows. So, why RXTX doesn't work under VM, but works under Linux and pure Windows XP (i tested it there) well? The send/receive method code follows. private String sendATCommand(String command, final String waitFor, final boolean isRegex, boolean isAddCRLF, long timeout) throws BeaconConnectException { final long POLL_PERIOD = 100; final int BUFFER_SIZE = 512; final byte[] buffer = new byte[BUFFER_SIZE]; final InputStream serialInput; final OutputStream serialOutput; try { serialInput = serialPort.getInputStream(); if (command != null) { serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } } catch (IOException e) { throw new MyException("serial I/O error"); } TimerTask task = new TimerTask() { int offset = 0; int bytesRead; public synchronized void run() { try { if (serialInput.available() > 0) { bytesRead = serialInput.read(buffer, offset, BUFFER_SIZE - offset); } else { return; } } catch (IOException e) { // do nothing - maybe next time we'll read something } offset += bytesRead; if (waitFor != null) { String temporary = new String(buffer, 0, offset).trim(); if (isRegex && temporary.matches(waitFor) || temporary.contains(waitFor)) { cancel(); notify(); } } } }; Timer timer = new Timer(); timer.schedule(task, POLL_PERIOD, POLL_PERIOD); synchronized (task) { try { task.wait(timeout); task.cancel(); } catch (InterruptedException e) { } } //Cut off leading and trailing CRs, LFs and zeroes String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); System.out.println(response); return response; } -- Pavel Parkhomenko From tjarvi at qbang.org Sun Mar 11 11:48:22 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:48:22 -0600 (MDT) Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: On Sun, 11 Mar 2007, Pavel Parkhomenko wrote: > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. > > private String sendATCommand(String command, final String waitFor, > final boolean isRegex, boolean isAddCRLF, long timeout) > throws BeaconConnectException > { > final long POLL_PERIOD = 100; > final int BUFFER_SIZE = 512; > final byte[] buffer = new byte[BUFFER_SIZE]; > final InputStream serialInput; > final OutputStream serialOutput; > try > { > serialInput = serialPort.getInputStream(); > if (command != null) > { > serialOutput = serialPort.getOutputStream(); > if (isAddCRLF) > { > command += "\r\n"; > } > System.out.println(command); > serialOutput.write(command.getBytes()); > } > } > catch (IOException e) > { > throw new MyException("serial I/O error"); > } > > TimerTask task = new TimerTask() > { > int offset = 0; > int bytesRead; > public synchronized void run() > { > try > { > if (serialInput.available() > 0) > { > bytesRead = serialInput.read(buffer, offset, > BUFFER_SIZE - offset); > } > else > { > return; > } > } > catch (IOException e) > { > // do nothing - maybe next time we'll read something > } > offset += bytesRead; > if (waitFor != null) > { > String temporary = new String(buffer, 0, offset).trim(); > if (isRegex && temporary.matches(waitFor) || > temporary.contains(waitFor)) > { > cancel(); > notify(); > } > } > } > }; > > Timer timer = new Timer(); > timer.schedule(task, POLL_PERIOD, POLL_PERIOD); > synchronized (task) { > try > { > task.wait(timeout); > task.cancel(); > } > catch (InterruptedException e) > { > } > } > //Cut off leading and trailing CRs, LFs and zeroes > String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); > System.out.println(response); > return response; > } > > > Hi Pavel VMWare should not be a problem. I've used it in the past - though not with a modem. Make sure nothing else is using the modem. Then look in the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an example that should work. Note that modems could care less what OS is on top. If you are trying to match new lines to the OS and sending it to the mode for AT commands, thats probably a mistake. Also it would not hurt to print out the individual bytes that you are sending to make sure they did not get mangled along the path. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 11:55:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:55:48 -0600 (MDT) Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: On Sun, 11 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > I have been a proponent of a JSR that makes > use of RXTX. I have executed the proper agreements with Sun. > > At this point we are in the: > Early Draft Review of Draft Specifications Stage. > > The best thing to do is to enter the quiet period and create > a specification. The question of exactly how we, as a group, > want to approach this problem, remains open. > > Typically, we should have both a specification and a reference > implementation. Thus, it would be to our best advantage to have > a nice, stable, cross platform RXTX distro that adheres to the > groups specification. > > Now, from a specification standpoint, my personal view on the matter is > that we create a series of interfaces, with nice documentation (or at least > javadoc). > > Is this a good idea? Should we have a pure interface specification for > the communication API? > > There are several issues, in my mind, which still weigh on us. > Hot-pluggable dongles, long discovery process on pop-up ports, > lack of uniformity on device names, lack of uniformity on locking, > a precise understanding of how the SerialPortResourceManager > works (or even if we should have one). > > The more questions we answer in our reference implementation, the > better our specification will get. RXTX is a good working prototype, > but, I don't know if that is what we want to use for a specification. > > Here is what I have for a CommPortInterface: > */ > public interface CommPortInterface { Hi Doug, I can start going through the method interfaces later this week and giving feedback. I would suggest that the JSR should not be too generic in nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel drivers that intend to look like EIA232 ports at the kernel driver level. some ideas: EIA232PortInterface TermiosInterface SerialPortInterface Something that differentiates this from thing like USB, I2C, ... which should not have to deal with legacy serial claiming to be the comm api. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 12:52:19 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 12:52:19 -0600 (MDT) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: No news is good news with these posts. I'll start the process of pinging legal a week from Monday on my end if nobody has objections to the proposal. I just want to make sure everyone has time to raise objections. Obviously, anyone can fork from a previous version if they don't like the new license. I suspect we can avoid that though. On Sun, 4 Mar 2007, Trent Jarvi wrote: > > For those that are wondering what is going on here, this > next bit is the meat of the changes. We agreed a long time > ago to put this disclaimer in. We did a so so job. It was > in rxtx 2.0, not well written, ... So some groups using > rxtx that would like to ship rxtx so users don't need to > download, install, go to the mail-list to find why it failed, > ... Then their legal teams tell them section 5 paragraph 2 > is a show stopper. > > That was never the intent. > > > Now going through what remains... > >> and might need a (TM) suffix to make Sun happy. > > Added disclaimer at the ended 'all trademarks belong...' > >> * Line #15ff - static vs. dynamic linking - you did >> not transcribe the text from the "controlled >> interface exception" when writing this text - and >> this was good so, because these terms originally >> refer to the GPL rather than the LGPL. I think though, >> that these 4 lines are the most important ones and >> should thus be really really clear. I hope that I >> meet your original intent with the following >> suggestions: >> 1.) Instead of "A program.." it would be better to >> say "An exectuable.." in order to be closer to >> the LGPL text. > > OK. As you can see I was trying to adjust GNU text there > for the LGPL. > >> 2.) It would be better to say .. "by being dynamically >> linked with it" to clearly indicate that dynamic >> linking is meant. The matter of compilation is >> already covered by the LGPL so mentioning it again >> just leads to confusion. > > used dynamically linked terminology. > >> 3.) It would be better to say .. "is considered a >> work that uses the library in contrast to section >> 5 of the LGPL, so the terms of the LGPL do not >> apply to the resulting executable". > > I tried to address this more upfront with an intent statement. > Let me know if you have problems with it. I also tried to > make it a little more clear what was derived from the GNU > solution by moving the link location closer to GNU's suggestion. > >> >> Note that LGPL section 5 says: ..."is called a >> "work that uses the Library". Such a work, in isolation, >> is not a derivative work of the Library, and therefore >> falls outside the scope of this License." >> The next paragraph of the LGPL is exactly the problematic >> one that I hope is clarified by the exception terms you >> give. >> > > Thats the intent. Here is the combined fixes. Note that only the > material in /*-- --*/ is being touched. The new GPL license is > there but unmodified. > > > ------------------------ begin proposed new license ------------------- > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Lesser General Public > | License as published by the Free Software Foundation; either > | version 2.1 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Lesser General Public License for more details. > | > | An executable that contains no derivative of any portion of RXTX, but > | is designed to work with RXTX by being dynamically linked with it, > | is considered a "work that uses the Library" subject to the terms and > | conditions of the GNU Lesser General Public License. > | > | The following has been added to the RXTX License to remove > | any confusion about linking to RXTX. We want to allow in part what > | section 5, paragraph 2 of the LGPL does not permit in the special > | case of linking over a controlled interface. The intent is to add a > | Java Specification Request or standards body defined interface in the > | future as another exception but one is not currently available. > | > | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface > | > | As a special exception, the copyright holders of RXTX give you > | permission to link RXTX with independent modules that communicate with > | RXTX solely through the Sun Microsytems CommAPI interface version 2, > | regardless of the license terms of these independent modules, and to copy > | and distribute the resulting combined work under terms of your choice, > | provided that every copy of the combined work is accompanied by a complete > | copy of the source code of RXTX (the version of RXTX used to produce the > | combined work), being distributed under the terms of the GNU Lesser General > | Public License plus this exception. An independent module is a > | module which is not derived from or based on RXTX. > | > | Note that people who make modified versions of RXTX are not obligated > | to grant this special exception for their modified versions; it is > | their choice whether to do so. The GNU Lesser General Public License > | gives permission to release a modified version without this exception; this > | exception also makes it possible to release a modified version which > | carries forward this exception. > | > | You should have received a copy of the GNU Lesser General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > | All trademarks belong to their respective owners. > --------------------------------------------------------------------------*/ > > The original GNU Lesser General Public License Follows. > > > GNU LESSER GENERAL PUBLIC LICENSE > Version 2.1, February 1999 > > Copyright (C) 1991, 1999 Free Software Foundation, Inc. > 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > Everyone is permitted to copy and distribute verbatim copies > of this license document, but changing it is not allowed. > > [This is the first released version of the Lesser GPL. It also counts > as the successor of the GNU Library Public License, version 2, hence > the version number 2.1.] > > Preamble > > The licenses for most software are designed to take away your > freedom to share and change it. By contrast, the GNU General Public > Licenses are intended to guarantee your freedom to share and change > free software--to make sure the software is free for all its users. > > This license, the Lesser General Public License, applies to some > specially designated software packages--typically libraries--of the > Free Software Foundation and other authors who decide to use it. You > can use it too, but we suggest you first think carefully about whether > this license or the ordinary General Public License is the better > strategy to use in any particular case, based on the explanations below. > > When we speak of free software, we are referring to freedom of use, > not price. Our General Public Licenses are designed to make sure that > you have the freedom to distribute copies of free software (and charge > for this service if you wish); that you receive source code or can get > it if you want it; that you can change the software and use pieces of > it in new free programs; and that you are informed that you can do > these things. > > To protect your rights, we need to make restrictions that forbid > distributors to deny you these rights or to ask you to surrender these > rights. These restrictions translate to certain responsibilities for > you if you distribute copies of the library or if you modify it. > > For example, if you distribute copies of the library, whether gratis > or for a fee, you must give the recipients all the rights that we gave > you. You must make sure that they, too, receive or can get the source > code. If you link other code with the library, you must provide > complete object files to the recipients, so that they can relink them > with the library after making changes to the library and recompiling > it. And you must show them these terms so they know their rights. > > We protect your rights with a two-step method: (1) we copyright the > library, and (2) we offer you this license, which gives you legal > permission to copy, distribute and/or modify the library. > > To protect each distributor, we want to make it very clear that > there is no warranty for the free library. Also, if the library is > modified by someone else and passed on, the recipients should know > that what they have is not the original version, so that the original > author's reputation will not be affected by problems that might be > introduced by others. > > Finally, software patents pose a constant threat to the existence of > any free program. We wish to make sure that a company cannot > effectively restrict the users of a free program by obtaining a > restrictive license from a patent holder. Therefore, we insist that > any patent license obtained for a version of the library must be > consistent with the full freedom of use specified in this license. > > Most GNU software, including some libraries, is covered by the > ordinary GNU General Public License. This license, the GNU Lesser > General Public License, applies to certain designated libraries, and > is quite different from the ordinary General Public License. We use > this license for certain libraries in order to permit linking those > libraries into non-free programs. > > When a program is linked with a library, whether statically or using > a shared library, the combination of the two is legally speaking a > combined work, a derivative of the original library. The ordinary > General Public License therefore permits such linking only if the > entire combination fits its criteria of freedom. The Lesser General > Public License permits more lax criteria for linking other code with > the library. > > We call this license the "Lesser" General Public License because it > does Less to protect the user's freedom than the ordinary General > Public License. It also provides other free software developers Less > of an advantage over competing non-free programs. These disadvantages > are the reason we use the ordinary General Public License for many > libraries. However, the Lesser license provides advantages in certain > special circumstances. > > For example, on rare occasions, there may be a special need to > encourage the widest possible use of a certain library, so that it becomes > a de-facto standard. To achieve this, non-free programs must be > allowed to use the library. A more frequent case is that a free > library does the same job as widely used non-free libraries. In this > case, there is little to gain by limiting the free library to free > software only, so we use the Lesser General Public License. > > In other cases, permission to use a particular library in non-free > programs enables a greater number of people to use a large body of > free software. For example, permission to use the GNU C Library in > non-free programs enables many more people to use the whole GNU > operating system, as well as its variant, the GNU/Linux operating > system. > > Although the Lesser General Public License is Less protective of the > users' freedom, it does ensure that the user of a program that is > linked with the Library has the freedom and the wherewithal to run > that program using a modified version of the Library. > > The precise terms and conditions for copying, distribution and > modification follow. Pay close attention to the difference between a > "work based on the library" and a "work that uses the library". The > former contains code derived from the library, whereas the latter must > be combined with the library in order to run. > > GNU LESSER GENERAL PUBLIC LICENSE > TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION > > 0. This License Agreement applies to any software library or other > program which contains a notice placed by the copyright holder or > other authorized party saying it may be distributed under the terms of > this Lesser General Public License (also called "this License"). > Each licensee is addressed as "you". > > A "library" means a collection of software functions and/or data > prepared so as to be conveniently linked with application programs > (which use some of those functions and data) to form executables. > > The "Library", below, refers to any such software library or work > which has been distributed under these terms. A "work based on the > Library" means either the Library or any derivative work under > copyright law: that is to say, a work containing the Library or a > portion of it, either verbatim or with modifications and/or translated > straightforwardly into another language. (Hereinafter, translation is > included without limitation in the term "modification".) > > "Source code" for a work means the preferred form of the work for > making modifications to it. For a library, complete source code means > all the source code for all modules it contains, plus any associated > interface definition files, plus the scripts used to control compilation > and installation of the library. > > Activities other than copying, distribution and modification are not > covered by this License; they are outside its scope. The act of > running a program using the Library is not restricted, and output from > such a program is covered only if its contents constitute a work based > on the Library (independent of the use of the Library in a tool for > writing it). Whether that is true depends on what the Library does > and what the program that uses the Library does. > > 1. You may copy and distribute verbatim copies of the Library's > complete source code as you receive it, in any medium, provided that > you conspicuously and appropriately publish on each copy an > appropriate copyright notice and disclaimer of warranty; keep intact > all the notices that refer to this License and to the absence of any > warranty; and distribute a copy of this License along with the > Library. > > You may charge a fee for the physical act of transferring a copy, > and you may at your option offer warranty protection in exchange for a > fee. > > 2. You may modify your copy or copies of the Library or any portion > of it, thus forming a work based on the Library, and copy and > distribute such modifications or work under the terms of Section 1 > above, provided that you also meet all of these conditions: > > a) The modified work must itself be a software library. > > b) You must cause the files modified to carry prominent notices > stating that you changed the files and the date of any change. > > c) You must cause the whole of the work to be licensed at no > charge to all third parties under the terms of this License. > > d) If a facility in the modified Library refers to a function or a > table of data to be supplied by an application program that uses > the facility, other than as an argument passed when the facility > is invoked, then you must make a good faith effort to ensure that, > in the event an application does not supply such function or > table, the facility still operates, and performs whatever part of > its purpose remains meaningful. > > (For example, a function in a library to compute square roots has > a purpose that is entirely well-defined independent of the > application. Therefore, Subsection 2d requires that any > application-supplied function or table used by this function must > be optional: if the application does not supply it, the square > root function must still compute square roots.) > > These requirements apply to the modified work as a whole. If > identifiable sections of that work are not derived from the Library, > and can be reasonably considered independent and separate works in > themselves, then this License, and its terms, do not apply to those > sections when you distribute them as separate works. But when you > distribute the same sections as part of a whole which is a work based > on the Library, the distribution of the whole must be on the terms of > this License, whose permissions for other licensees extend to the > entire whole, and thus to each and every part regardless of who wrote > it. > > Thus, it is not the intent of this section to claim rights or contest > your rights to work written entirely by you; rather, the intent is to > exercise the right to control the distribution of derivative or > collective works based on the Library. > > In addition, mere aggregation of another work not based on the Library > with the Library (or with a work based on the Library) on a volume of > a storage or distribution medium does not bring the other work under > the scope of this License. > > 3. You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. To do > this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version 2, > instead of to this License. (If a newer version than version 2 of the > ordinary GNU General Public License has appeared, then you can specify > that version instead if you wish.) Do not make any other change in > these notices. > > Once this change is made in a given copy, it is irreversible for > that copy, so the ordinary GNU General Public License applies to all > subsequent copies and derivative works made from that copy. > > This option is useful when you wish to copy part of the code of > the Library into a program that is not a library. > > 4. You may copy and distribute the Library (or a portion or > derivative of it, under Section 2) in object code or executable form > under the terms of Sections 1 and 2 above provided that you accompany > it with the complete corresponding machine-readable source code, which > must be distributed under the terms of Sections 1 and 2 above on a > medium customarily used for software interchange. > > If distribution of object code is made by offering access to copy > from a designated place, then offering equivalent access to copy the > source code from the same place satisfies the requirement to > distribute the source code, even though third parties are not > compelled to copy the source along with the object code. > > 5. A program that contains no derivative of any portion of the > Library, but is designed to work with the Library by being compiled or > linked with it, is called a "work that uses the Library". Such a > work, in isolation, is not a derivative work of the Library, and > therefore falls outside the scope of this License. > > However, linking a "work that uses the Library" with the Library > creates an executable that is a derivative of the Library (because it > contains portions of the Library), rather than a "work that uses the > library". The executable is therefore covered by this License. > Section 6 states terms for distribution of such executables. > > When a "work that uses the Library" uses material from a header file > that is part of the Library, the object code for the work may be a > derivative work of the Library even though the source code is not. > Whether this is true is especially significant if the work can be > linked without the Library, or if the work is itself a library. The > threshold for this to be true is not precisely defined by law. > > If such an object file uses only numerical parameters, data > structure layouts and accessors, and small macros and small inline > functions (ten lines or less in length), then the use of the object > file is unrestricted, regardless of whether it is legally a derivative > work. (Executables containing this object code plus portions of the > Library will still fall under Section 6.) > > Otherwise, if the work is a derivative of the Library, you may > distribute the object code for the work under the terms of Section 6. > Any executables containing that work also fall under Section 6, > whether or not they are linked directly with the Library itself. > > 6. As an exception to the Sections above, you may also combine or > link a "work that uses the Library" with the Library to produce a > work containing portions of the Library, and distribute that work > under terms of your choice, provided that the terms permit > modification of the work for the customer's own use and reverse > engineering for debugging such modifications. > > You must give prominent notice with each copy of the work that the > Library is used in it and that the Library and its use are covered by > this License. You must supply a copy of this License. If the work > during execution displays copyright notices, you must include the > copyright notice for the Library among them, as well as a reference > directing the user to the copy of this License. Also, you must do one > of these things: > > a) Accompany the work with the complete corresponding > machine-readable source code for the Library including whatever > changes were used in the work (which must be distributed under > Sections 1 and 2 above); and, if the work is an executable linked > with the Library, with the complete machine-readable "work that > uses the Library", as object code and/or source code, so that the > user can modify the Library and then relink to produce a modified > executable containing the modified Library. (It is understood > that the user who changes the contents of definitions files in the > Library will not necessarily be able to recompile the application > to use the modified definitions.) > > b) Use a suitable shared library mechanism for linking with the > Library. A suitable mechanism is one that (1) uses at run time a > copy of the library already present on the user's computer system, > rather than copying library functions into the executable, and (2) > will operate properly with a modified version of the library, if > the user installs one, as long as the modified version is > interface-compatible with the version that the work was made with. > > c) Accompany the work with a written offer, valid for at > least three years, to give the same user the materials > specified in Subsection 6a, above, for a charge no more > than the cost of performing this distribution. > > d) If distribution of the work is made by offering access to copy > from a designated place, offer equivalent access to copy the above > specified materials from the same place. > > e) Verify that the user has already received a copy of these > materials or that you have already sent this user a copy. > > For an executable, the required form of the "work that uses the > Library" must include any data and utility programs needed for > reproducing the executable from it. However, as a special exception, > the materials to be distributed need not include anything that is > normally distributed (in either source or binary form) with the major > components (compiler, kernel, and so on) of the operating system on > which the executable runs, unless that component itself accompanies > the executable. > > It may happen that this requirement contradicts the license > restrictions of other proprietary libraries that do not normally > accompany the operating system. Such a contradiction means you cannot > use both them and the Library together in an executable that you > distribute. > > 7. You may place library facilities that are a work based on the > Library side-by-side in a single library together with other library > facilities not covered by this License, and distribute such a combined > library, provided that the separate distribution of the work based on > the Library and of the other library facilities is otherwise > permitted, and provided that you do these two things: > > a) Accompany the combined library with a copy of the same work > based on the Library, uncombined with any other library > facilities. This must be distributed under the terms of the > Sections above. > > b) Give prominent notice with the combined library of the fact > that part of it is a work based on the Library, and explaining > where to find the accompanying uncombined form of the same work. > > 8. You may not copy, modify, sublicense, link with, or distribute > the Library except as expressly provided under this License. Any > attempt otherwise to copy, modify, sublicense, link with, or > distribute the Library is void, and will automatically terminate your > rights under this License. However, parties who have received copies, > or rights, from you under this License will not have their licenses > terminated so long as such parties remain in full compliance. > > 9. You are not required to accept this License, since you have not > signed it. However, nothing else grants you permission to modify or > distribute the Library or its derivative works. These actions are > prohibited by law if you do not accept this License. Therefore, by > modifying or distributing the Library (or any work based on the > Library), you indicate your acceptance of this License to do so, and > all its terms and conditions for copying, distributing or modifying > the Library or works based on it. > > 10. Each time you redistribute the Library (or any work based on the > Library), the recipient automatically receives a license from the > original licensor to copy, distribute, link with or modify the Library > subject to these terms and conditions. You may not impose any further > restrictions on the recipients' exercise of the rights granted herein. > You are not responsible for enforcing compliance by third parties with > this License. > > 11. If, as a consequence of a court judgment or allegation of patent > infringement or for any other reason (not limited to patent issues), > conditions are imposed on you (whether by court order, agreement or > otherwise) that contradict the conditions of this License, they do not > excuse you from the conditions of this License. If you cannot > distribute so as to satisfy simultaneously your obligations under this > License and any other pertinent obligations, then as a consequence you > may not distribute the Library at all. For example, if a patent > license would not permit royalty-free redistribution of the Library by > all those who receive copies directly or indirectly through you, then > the only way you could satisfy both it and this License would be to > refrain entirely from distribution of the Library. > > If any portion of this section is held invalid or unenforceable under any > particular circumstance, the balance of the section is intended to apply, > and the section as a whole is intended to apply in other circumstances. > > It is not the purpose of this section to induce you to infringe any > patents or other property right claims or to contest validity of any > such claims; this section has the sole purpose of protecting the > integrity of the free software distribution system which is > implemented by public license practices. Many people have made > generous contributions to the wide range of software distributed > through that system in reliance on consistent application of that > system; it is up to the author/donor to decide if he or she is willing > to distribute software through any other system and a licensee cannot > impose that choice. > > This section is intended to make thoroughly clear what is believed to > be a consequence of the rest of this License. > > 12. If the distribution and/or use of the Library is restricted in > certain countries either by patents or by copyrighted interfaces, the > original copyright holder who places the Library under this License may add > an explicit geographical distribution limitation excluding those countries, > so that distribution is permitted only in or among countries not thus > excluded. In such case, this License incorporates the limitation as if > written in the body of this License. > > 13. The Free Software Foundation may publish revised and/or new > versions of the Lesser General Public License from time to time. > Such new versions will be similar in spirit to the present version, > but may differ in detail to address new problems or concerns. > > Each version is given a distinguishing version number. If the Library > specifies a version number of this License which applies to it and > "any later version", you have the option of following the terms and > conditions either of that version or of any later version published by > the Free Software Foundation. If the Library does not specify a > license version number, you may choose any version ever published by > the Free Software Foundation. > > 14. If you wish to incorporate parts of the Library into other free > programs whose distribution conditions are incompatible with these, > write to the author to ask for permission. For software which is > copyrighted by the Free Software Foundation, write to the Free > Software Foundation; we sometimes make exceptions for this. Our > decision will be guided by the two goals of preserving the free status > of all derivatives of our free software and of promoting the sharing > and reuse of software generally. > > NO WARRANTY > > 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO > WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. > EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR > OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY > KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE > IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE > LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME > THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. > > 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN > WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY > AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU > FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR > CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE > LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING > RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A > FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF > SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH > DAMAGES. > > END OF TERMS AND CONDITIONS > > How to Apply These Terms to Your New Libraries > > If you develop a new library, and you want it to be of the greatest > possible use to the public, we recommend making it free software that > everyone can redistribute and change. You can do so by permitting > redistribution under these terms (or, alternatively, under the terms of the > ordinary General Public License). > > To apply these terms, attach the following notices to the library. It is > safest to attach them to the start of each source file to most effectively > convey the exclusion of warranty; and each file should have at least the > "copyright" line and a pointer to where the full notice is found. > > > Copyright (C) > > This library is free software; you can redistribute it and/or > modify it under the terms of the GNU Lesser General Public > License as published by the Free Software Foundation; either > version 2.1 of the License, or (at your option) any later version. > > This library is distributed in the hope that it will be useful, > but WITHOUT ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > Lesser General Public License for more details. > > You should have received a copy of the GNU Lesser General Public > License along with this library; if not, write to the Free Software > Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > > Also add information on how to contact you by electronic and paper mail. > > You should also get your employer (if you work as a programmer) or your > school, if any, to sign a "copyright disclaimer" for the library, if > necessary. Here is a sample; alter the names: > > Yoyodyne, Inc., hereby disclaims all copyright interest in the > library `Frob' (a library for tweaking knobs) written by James Random Hacker. > > , 1 April 1990 > Ty Coon, President of Vice > > That's all there is to it! > ------------------------ end of proposed license ------------------ > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From gjhanna at gmail.com Sun Mar 11 14:21:17 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Mon, 12 Mar 2007 09:21:17 +1300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hi Pavel, We are using RXTX under VMWare server in production, quite satisfactorily. We're using Red Hat Enterprise Server 4, and ... Whatever the "enterprise" VMWare product is. Regards, Greg H > Subject: [Rxtx] RXTX under VMWare server > To: rxtx at qbang.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. [ ... snip ... ] -- Pavel Parkhomenko -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070311/4cebb6f9/attachment-0001.html From gergg at cox.net Sun Mar 11 23:39:19 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 12 Mar 2007 00:39:19 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: <45F4E787.6050502@cox.net> Trent Jarvi wrote: > I can start going through the method interfaces later this week and giving > feedback. I would suggest that the JSR should not be too generic in > nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel > drivers that intend to look like EIA232 ports at the kernel driver level. > > some ideas: > > EIA232PortInterface > TermiosInterface > SerialPortInterface > > Something that differentiates this from thing like USB, I2C, ... which > should not have to deal with legacy serial claiming to be the comm api. I'm going to throw out a suggestion, which I am mostly serious about. What would happen if we took the appropriate bits of the J2ME connector API, and just used that as the new COMM API so that finally JSE and JME had a common foundation for these kinds of things? Gregg Wonderly From ra85551 at gmail.com Mon Mar 12 09:08:37 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Mon, 12 Mar 2007 18:08:37 +0300 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Should any application use the modem, HyperTerminal won't be able to talk to the modem. But it actually can send and receive AT comands, while my application cannot :-( > Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Thansk for the reference. I examined that example and found that there's no significant differences between my read/write implementation and that one, except that SimpleSnuV1 listens for serialEvent's, but not for sake of data retrieval, just for printing them out - I don't know why ;-) > Note that modems could care less what OS is on top. If you are trying to > match new lines to the OS and sending it to the mode for AT commands, > thats probably a mistake. I do send strings to serial port, not to OS, and do try to get answers back. If it is the mistake, what's the right way? > Also it would not hurt to print out the > individual bytes that you are sending to make sure they did not get > mangled along the path. Yeah, I am printing these bytes before doing write, but it means that I only see what I intend to write. How can I ensure that these bytes have gone out of the box and reached my modem? BTW, I found that my send/receive method is complex enough, so I've rewritten it. Please, see the following code and point any mistakes, because I don't know where can they remain yet. private static final int LARGE_TIMEOUT = 15000; private static final int SMALL_TIMEOUT = 500; ... private String sendATCommand(String command, String waitFor, boolean isRegex, boolean isAddCRLF) throws BeaconConnectException { byte[] buffer = new byte[512]; int offset; String result = ""; try { if (waitFor != null) { serialPort.enableReceiveTimeout(LARGE_TIMEOUT); } else { serialPort.enableReceiveTimeout(SMALL_TIMEOUT); } if (command != null) { OutputStream serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } offset = 0; InputStream serialInput = serialPort.getInputStream(); while (serialInput.available() != -1) { int bytesRead = serialInput.read(buffer, offset, buffer.length - offset); if (bytesRead == 0) { break; } offset += bytesRead; result = new String(buffer, 0, offset).trim(); if (waitFor != null) { System.out.println(result); if (isRegex && result.matches(waitFor) || result.contains(waitFor)) { break; } } } } catch (UnsupportedCommOperationException e) { throw new MyException("unsupported operation"); } catch (IOException e) { throw new MytException("serial I/O error"); } return result; } -- Pavel Parkhomenko From clayno at hotpop.com Thu Mar 15 02:47:34 2007 From: clayno at hotpop.com (Christopher Layno) Date: Thu, 15 Mar 2007 16:47:34 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi, we're using the latest release of rxtx (2.1-7r2) for our system that has two applications using the library. one application sends requests to the modem while the other simply checks the modem status. we deployed our system on a pentium machine with red hat linux 9.0 installed. now the problem arises when these two applications try to access the same modem at the same time. one of them will eventually have to throw the PortInUseException as shown below: 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException gnu.io.PortInUseException: root PID = 743 Program = java root PID = 743 Program = java root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) this was expected. what we didn't expect though was that if we repeat the scenario 5 times, always 5 times, the application would also throw a VM error: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4473CD21 Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so Current Java thread: at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) - locked <0x44cfd4c8> (a gnu.io.CommPortIdentifier) at ************ at ************ - locked <0x4476a468> (a **********) at ************ at ************ at ************ at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java :261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages( TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run( TCPTransport.java:701) at java.lang.Thread.run(Thread.java:534) note: i replaced some sensitive data with asterisks our team has looked everywhere on the internet, including your mail archives, for a solution to this problem but to no avail. i really hope you could help us out on this one. thanks in advance! best regards, chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070315/1936460a/attachment-0001.html From tjarvi at qbang.org Fri Mar 16 04:30:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 04:30:25 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: On Thu, 15 Mar 2007, Christopher Layno wrote: > hi, > > we're using the latest release of rxtx (2.1-7r2) for our system that has two > applications using the library. one application sends requests to the modem > while the other simply checks the modem status. we deployed our system on a > pentium machine with red hat linux 9.0 installed. > > now the problem arises when these two applications try to access the same > modem at the same time. one of them will eventually have to throw the > PortInUseException as shown below: > > 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException > gnu.io.PortInUseException: root PID = 743 Program = java root PID = > 743 Program = java root PID = 743 Program = ??? root PID = 743 Program > = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root > PID = 743 Program = ??? root PID = 743 Program = ??? > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > > this was expected. what we didn't expect though was that if we repeat the > scenario 5 times, always 5 times, the application would also throw a VM > error: > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x4473CD21 > Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 > Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so > > Current Java thread: > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) Hi Chris The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. The code is originally by Werner Almesberger. He gave us permission to use it in rxtx. You might look at what has changed since 1998 in his fuser application. Or you can just do like other OSs and do the following in fuserImp.c JNIEXPORT jstring JNICALL Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv *env, jobject obj, jstring arg) { return (*env)->NewStringUTF(env, "Unknown Application"); } It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. -- Trent Jarvi tjarvi at qang.org From Adrien.TOS at ingenico.com Fri Mar 16 05:11:12 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Fri, 16 Mar 2007 12:11:12 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903CBC312@frsnprexc1.usr.ingenico.loc> Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070316/972ab214/attachment-0001.html From joachim at buechse.de Fri Mar 16 05:13:24 2007 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 16 Mar 2007 12:13:24 +0100 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. From tjarvi at qbang.org Fri Mar 16 16:36:29 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 16:36:29 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Fri Mar 16 16:02:23 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 16 Mar 2007 18:02:23 -0400 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Not all platforms are Unix based. Also mixing native library usage and command-line calls is not an elegant solution, IMHO. One or the other, but not both. Andre On 16-Mar-07, at 07:13 , Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is > trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We >> only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From clayno at hotpop.com Sun Mar 18 22:17:28 2007 From: clayno at hotpop.com (Christopher Layno) Date: Mon, 19 Mar 2007 12:17:28 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi everyone, thank you so much for your replies. they were really helpful. anyway, before i sent the email, my team was already implementing a temporary solution by using joachim's suggestion. we invoked a lsof command from our java code although i share the same concern with trent and andre-john about portability issues. that's why i said it's just temporary. my superiors have yet to approve our bug fix. so my question now is this: is recompiling the rxtx source code the only way to solve this problem? because if it's the only solution, then i think my superiors would rather have a new release from the rxtx community itself that fixes this bug(?) rather than have my team recompile the source code. best regards, chris Trent Jarvi wrote: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. ... It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070318/237463b2/attachment-0001.html From tjarvi at qbang.org Mon Mar 19 16:20:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Mar 2007 16:20:52 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: Hi Chris I can compile a new version after the 21st if you do not feel comfortable doing so. Please send me an email reminder off-line then. On Mon, 19 Mar 2007, Christopher Layno wrote: > hi everyone, > > thank you so much for your replies. they were really helpful. > > anyway, before i sent the email, my team was already implementing a > temporary solution by using joachim's suggestion. > we invoked a lsof command from our java code although i share the same > concern with trent and andre-john about > portability issues. that's why i said it's just temporary. my superiors have > yet to approve our bug fix. > > so my question now is this: is recompiling the rxtx source code the only way > to solve this problem? because if it's the only > solution, then i think my superiors would rather have a new release from the > rxtx community itself that fixes this bug(?) > rather than have my team recompile the source code. > > best regards, > > chris > > Trent Jarvi wrote: > > Hi Joachim > > It would be nice to have that functionality but calling the program > introduces too many issues imho. Explaining to someone why rxtx invoked a > rogue lsof does not sound very interesting. > > On Fri, 16 Mar 2007, Joachim Buechse wrote: > > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: > > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. > > _______________________________________________ > Rxtx mailing list > Rxtx 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 Eric.Arseneau at sun.com Tue Mar 20 11:47:33 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Tue, 20 Mar 2007 10:47:33 -0700 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 Message-ID: <46001E35.9040608@sun.com> Anyone have any experience with RXTX working with JDK 6 on other platforms ? From mm at UDel.Edu Tue Mar 20 12:18:29 2007 From: mm at UDel.Edu (Mike Markowski) Date: Tue, 20 Mar 2007 14:18:29 -0400 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 In-Reply-To: <46001E35.9040608@sun.com> References: <46001E35.9040608@sun.com> Message-ID: <46002575.4000306@udel.edu> Eric Arseneau wrote: > Anyone have any experience with RXTX working with JDK 6 on other platforms ? I'm using 32 bit intel, gentoo linux, jdk6 with no problems. My applications only use a serial port, though, nothing on the parallel port. Mike From falko.guderian at gmx.de Wed Mar 21 08:17:35 2007 From: falko.guderian at gmx.de (Falko Guderian) Date: Wed, 21 Mar 2007 15:17:35 +0100 Subject: [Rxtx] RXTX binaries for SH4 Message-ID: <46013E7F.40102@gmx.de> Dear developers, I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no possiblities to compile the source code. Better, I'm not able to do this at the moment. Can you provide me with rxtxSerial.dll (SH4) in the rxtx-2.1-8-testing version? (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) The reason for the testing version is I need custom baud rates. Thanks for help. Kind regards, Falko Guderian From tjarvi at qbang.org Wed Mar 21 21:38:37 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Mar 2007 21:38:37 -0600 (MDT) Subject: [Rxtx] RXTX binaries for SH4 In-Reply-To: <46013E7F.40102@gmx.de> References: <46013E7F.40102@gmx.de> Message-ID: On Wed, 21 Mar 2007, Falko Guderian wrote: > Dear developers, > > I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no > possiblities to compile the source code. Better, I'm not able to do this > at the moment. Can you provide me with rxtxSerial.dll (SH4) in the > rxtx-2.1-8-testing version? > (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) > > The reason for the testing version is I need custom baud rates. > > Thanks for help. > Hi Falko WinCE binary format is not supported by gcc. That makes compiling limited to those familiar with the WinCE tools. I hope someone is able to provide them for you but it is not likely. WinCE has been compiled by others in the past but rxtx.org builds have never included WinCE. There is some information with the source concerning WinCE builds if you decide to do it. We can share your results too if you like. The source in the WinCE has never been updated for the custom baud rate. That would need changes from the main source I presume. If you look at the source, you will note that Michal Hobot created a mini fork in the source to handle wince but it has not been updated for 3 years. -- Trent Jarvi tjarvi at qbang.org From Adrien.TOS at ingenico.com Thu Mar 22 07:08:55 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Thu, 22 Mar 2007 14:08:55 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Hi everybody, Do you have any comments on this issue? Thanks! AT ________________________________ De : Adrien TOS Envoy? : vendredi 16 mars 2007 12:11 ? : 'rxtx at qbang.org' Cc : Adrien TOS Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070322/2306c538/attachment-0001.html From jeremy.reeve at zen.co.uk Mon Mar 19 07:36:04 2007 From: jeremy.reeve at zen.co.uk (Jeremy S. Reeve) Date: Mon, 19 Mar 2007 13:36:04 +0000 Subject: [Rxtx] rxtx failing to compile on Fedora Core 6 Message-ID: <1174311364.21865.6.camel@d9thc> When trying to compile latest source : rxtx-2.1-7r2 I get the following when running configure: ---------------- checking os.version 2.6.18-1.2200.fc5smp WARNING: configure is having a hard time determining which directory contains the file jni_md.h. Edit Makefile and fix the variable JAVANATINC to point to the correct directory. The following options are available: /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/ /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/linux/ If there are more than one option available the first was selected. WARNING: Kernel include files do not match the current kernel configure: creating ./config.status ------------------------ which seems OK checking the resultant Makefile but when attempting to build with gmake install I get the following output : ---------------------- 34 problems (34 warnings)/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/javah -classpath .:/home/jsr/rxtxsrc/rxtx-2.1-7r2:/home/jsr/rxtxsrc/rxtx-2.1-7r2/src:/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/ext/RXTXcomm.jar -d i686-pc-linux-gnu -jni `(for i in CommDriver CommPortEnumerator CommPortIdentifier CommPort CommPortOwnershipListener Configure I2C I2CPortEvent I2CPortEventListener I2CPort LPRPort NoSuchPortException ParallelPortEvent ParallelPortEventListener ParallelPort PortInUseException Raw RawPortEvent RawPortEventListener RawPort RS485 RS485PortEvent RS485PortEventListener RS485Port RXTXCommDriver RXTXPort RXTXVersion SerialPortEvent SerialPortEventListener SerialPort UnsupportedCommOperationException UnSupportedLoggerException Zystem;do \ if grep > /dev/null native.* \( /home/jsr/rxtxsrc/rxtx-2.1-7r2/./src/$i.java; then \ echo gnu.io.$i; \ fi; \ done)` i686-pc-linux-gnu/gnu_io_CommPortIdentifier.h: No such file or directory make: *** [/home/jsr/rxtxsrc/rxtx-2.1-7r2/gnu/io/CommDriver.class] Error 1 ------------------------ Any ideas or pointers? Regards, Jeremy From tjarvi at qbang.org Sat Mar 24 08:12:54 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 Mar 2007 08:12:54 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > From Adrien.TOS at ingenico.com Sat Mar 24 11:53:22 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Sat, 24 Mar 2007 18:53:22 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> I do not have the threshold setting enabled, I have explicitely disabled it with: port_.disableReceiveThreshold(); I have also run the same tests with the threshold setting enabled, but they also fail in the same way as described below. So it seems there is a problem with timeout handling on Win32? ________________________________ From: rxtx-bounces at qbang.org on behalf of Trent Jarvi Sent: Sat 3/24/2007 3:12 PM To: RXTX Developers and Users Subject: Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 8312 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20070324/f9e39c9b/attachment-0001.bin From greg.johnson at manchester.ac.uk Sun Mar 25 13:41:36 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Sun, 25 Mar 2007 21:41:36 +0200 Subject: [Rxtx] Mac intel weirdness Message-ID: Hi folks, I'm trying to get rxtx to work on my macbook pro with a USB-serial dongle on it. I am using the 2.1-8 code from the CVS (though it seems to report itself as 2.1-7: makes it difficult to prove to oneself that the changes have 'taken'! - line 4210 in SerialImp.c, line 40 in RXTXVersion.java) I am trying the 2.1-8 because of horrible lock problems in 2.1-7. However, the serialport closure code seems to be broken - it won't close because it believes the (previously opened!) port doesn't exist. Here is what I'm trying: 0. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "false" 1. Open a port Serialport serialport = (SerialPort) commportidentifier.open ("test",100); 2. Talk to a device ... 3. Close port serialport.close(); 4. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "true" - why is this? 5. Try to reopen port Serialport serialport2 = (SerialPort) commportidentifier.open("test", 100); throws PortInUseException. I've dug around a bit in the source, and it seems the SerialPort.close () should call the CommPortIdentifier.internalClosePort() (line 67 of CommPort.java). However, I crash out with the NoSuchPortException when getPortIdentifier is called. Which seems quite weird to me, seeing as it is called on this - which was create just beforehand. Does anyone know how to fix this? Cheers, greg From knute at frazmtn.com Sat Mar 24 10:32:38 2007 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 24 Mar 2007 09:32:38 -0700 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc>, Message-ID: <4604F036.17833.135298@knute.frazmtn.com> > >The behavior of timeout depends upon the setting of the threshold. Do you >have the threshold setting? > This is the same bug I reported last fall. There was a fellow that sent me an email asking if it had been fixed. I told him I didn't think so. He got somebody to write a fix for him but I have not been able to contact him again for the actual changes. The inaccurate timeout and the failure of blocking when no timeouts are set is a serious bug in my humble opinion and renders the software unusable for my applications. I'd really like to have an alternative to the Sun comm api but there just isn't one that I know of. -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Mar 26 16:17:00 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 26 Mar 2007 16:17:00 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> Message-ID: >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. From ra85551 at gmail.com Tue Mar 27 10:18:36 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Tue, 27 Mar 2007 20:18:36 +0400 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Ultimately I found a solution. At first, that wasn't actually the VMWare + WinXP + RXTX issue, that was WinXP + RXTX issue. But on pure XP it sometimes workes, sometimes not, while under VMWare I had never seen my snippet working at all. SimpleSnuV1.java would not help me, because there is only one line I missed, and SimpleSnuV1.java also doesn't contain it! It is as follows: serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_OUT | SerialPort.FLOWCONTROL_RTSCTS_IN); Thank you for your attention. -- Pavel Parkhomenko From griff at op.pl Wed Mar 28 01:28:19 2007 From: griff at op.pl (griff@op.pl) Date: Wed, 28 Mar 2007 09:28:19 +0200 Subject: [Rxtx] No blocking read on Windows. Message-ID: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/5d07d571/attachment-0001.html -------------- next part -------------- Hi, I have problem that InputStram.read() (SerialPort)?returns -1 instead blocking and waiting for data. I found that this problem was ?known in 2005 : ? >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > >> Hi Trent >> >> Thanks for the fast response. >> Here's a Q&D test program for the blocking read on windows that just >> attempts to read one byte, and prints the resulting byte. On my system it >> returns -1, where I expect that it keeps waiting for data. >> >This isn't happening on Linux so the bug is in src/termios.c.? I'll have >something this weekend to fix that. I'm using RXTX 2.1.7r2 and the problem still is here. Im using Windows XP and java 1.5 disableReciveTimeout() and disableReciveTreshhold() dont help. ? best regards ? Piotr Zielniok From Adrien.TOS at ingenico.com Wed Mar 28 01:40:46 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Wed, 28 Mar 2007 09:40:46 +0200 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903E88880@frsnprexc1.usr.ingenico.loc> Looking at the code, it seems there is no support for infinite timeout? And maybe the count++ < 20 condition is breaking out of the loop too early? The only condition to break out of the loop should either be the timeout has expired or the number of requested bytes has been received. -----Message d'origine----- De : rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] De la part de Trent Jarvi Envoy? : mardi 27 mars 2007 00:17 ? : RXTX Developers and Users Objet : Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From j.kenneth.gentle at acm.org Wed Mar 28 06:44:15 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 28 Mar 2007 08:44:15 -0400 Subject: [Rxtx] No blocking read on Windows. In-Reply-To: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> References: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> Message-ID: <200703281844.l2SIiITW028614@qbang.org> Just another "ME TOO!" - I'm seeing this problem on Windows XP, jre for windows XP/Embedded. I cranked receiveTimeout up to Integer.MAX_INT, but it doesn't seem to wait that long At 03:28 2007-03-28, you wrote: >Hi, >I have problem that InputStram.read() (SerialPort) returns -1 >instead blocking and waiting for data. I found that this problem >was known in 2005 : > > >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > > > >> Hi Trent > >> > >> Thanks for the fast response. > >> Here's a Q&D test program for the blocking read on windows that just > >> attempts to read one byte, and prints the resulting byte. On my system it > >> returns -1, where I expect that it keeps waiting for data. > >> > > >This isn't happening on Linux so the bug is in src/termios.c. I'll have > >something this weekend to fix that. > >I'm using RXTX 2.1.7r2 and the problem still is here. >Im using Windows XP and java 1.5 >disableReciveTimeout() and disableReciveTreshhold() dont help. > >best regards > >Piotr Zielniok > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From greg.johnson at manchester.ac.uk Wed Mar 28 14:43:29 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Wed, 28 Mar 2007 22:43:29 +0200 Subject: [Rxtx] Cannot close and reopen serial port Message-ID: <377F9765-7A9D-4CE9-9176-FFB63A2594F0@manchester.ac.uk> Dear all, It appears I cannot close a port properly: SerialPort serialport = portid.open("myprog",100); // do some stuff, all works fine serialport.close(); // all seems fine but... SerialPort sp2 = portid.open("myprog",100); throws PortInUseException. And when I dig into the rxtx code, I find in CommPort.java, in close(): CommPortIdentifier cp = CommPortIdentifier.getPortIdentifier(this); (line 64 or there abouts) but this throws a NoSuchPortException which is caught but ignored (line 74ish). Can anyone suggest how this could happen: a port that was valid, opened, and used, throws a NSPE when it comes to closing it? I'm pulling my (remaining) hair out over this one! Cheers, greg PS And thanks for RXTX - it's great to have! PPS (21.-7. winxp/osx both, java 1.5) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/c28852fc/attachment-0001.html From rxtx at vrijheidslaan.net Fri Mar 30 16:52:50 2007 From: rxtx at vrijheidslaan.net (Rob) Date: Fri, 30 Mar 2007 22:52:50 -0000 Subject: [Rxtx] Cvs Question Message-ID: <61896.80.126.150.87.1175295162.squirrel@webmail.provalue.nl> Hi There, Im trying to get the latest version to work on mac osx. Problem is that i can't checkout version 2.1.8. Probably my fault but can some one please give me the alternative commands for: [user at myhost]$ export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot [user at myhost]$ cvs login Thanx, Rob From ra85551 at gmail.com Thu Mar 1 03:47:06 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Thu, 1 Mar 2007 13:47:06 +0300 Subject: [Rxtx] enableReceiveTimeout() issue Message-ID: Hello, world! I found a limitation of 16300 ms for CommPort's enableReceiveTimeout() method, while in original javax.comm docs there are no any references to that. Is that a bug or feature? I actually need longer timeouts sometimees. -- Pavel Parkhomenko From lyon at docjava.com Thu Mar 1 07:54:17 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 01 Mar 2007 09:54:17 -0500 Subject: [Rxtx] parametric singleton design pattern In-Reply-To: References: <22d55aea0702081207q5e7f6785l352d498d6f5f9fb1@mail.gmail.com> <22d55aea0702100034o3bcf42f3j1d1a6257029a67b0@mail.gmail.com> Message-ID: Hi All, I have been thinking about the use of a design pattern to cache resources that are consumed by processes. Toward that end, I have arrived at a parametric singleton design pattern, which I mentioned on this list some time ago. The idea has been published at: http://www.jot.fm/issues/issue_2007_03/column2 I can't help but think that there should be an API available for dealing with the tracking of serial port usage. Perhaps it is a kind of resource manager called the: SerialPortManager basic prototypes already exist in this vain. See, for example: http://www.ce.rit.edu/research/projects/2005_fall/rt_poolsystem/doc/PoolMon/SerialPortManager.html http://www.eventhelix.com/RealtimeMantra/PatternCatalog/serial_port_design_pattern.htm And others shown by a google search on "SerialPortManager" Cheers! - Doug From Eric.Arseneau at sun.com Thu Mar 1 10:15:03 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:15:03 -0800 Subject: [Rxtx] Any known Java 6 issues with RXTX 2.1-7r2 ? Message-ID: <45E70A17.1060206@sun.com> I just did a test on a recent build of Solaris 11 x86 and it seems that I can connect to my serial device fine when Java 5 is the default, but when Java 6 is the default, no go. Any information ? From Eric.Arseneau at sun.com Thu Mar 1 10:19:58 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:19:58 -0800 Subject: [Rxtx] Mac OS X and missing data Message-ID: <45E70B3E.7040908@sun.com> We have a device which is USB based but presents itself as a serial port to a machine. On my MacBook Pro I can get excellent throughput if I get my device to send data as quickly as possible. On the desktop side, if I do an type of disk IO to log the data I get, I end up with some missing data at some point. I hooked up a USB analyzer and did confirm that all the data is sent as expected to the desktop from the device. I found a work around for this, buffer the data in memory and only write the data out when I've received it all. However, when the same code and same device is attempted on a co-workers MacBook Pro (same hardware specs), I get errors and must slow down dramatically the device side's sending of data. Any ideas/recommendations on what I can do to get rid of this error ? From what I can tell, it seems that RXTX is not able to wake up to the interrupts coming in indicating data is ready, quickly enough, is there anything I can do ? From chinkaiw at hotmail.com Fri Mar 2 00:57:43 2007 From: chinkaiw at hotmail.com (Wang Chinkai) Date: Fri, 02 Mar 2007 07:57:43 +0000 Subject: [Rxtx] dynamic detect rs232 port Message-ID: Hi all I have a question about detecting rs232 port dynamicly. I have to aceess some port and detect rs232 port at the same time. Some usb device simulates rs232 port , and I can not know what the port name it gets until it connects,so I have to detect it dynamic,but I have to access another rs232 device at the same time. I found a problem. If I use CommPortIdentifier.getPortIdentifiers() to get new port list , and the other rs232 access function will not close port correctly. So , How can I solve it . Thanks. _________________________________________________________________ ?? 2GB ???? Windows Live Mail ????????????? http://ideas.live.com/programpage.aspx?versionid=5d21c51a-b161-4314-9b0e-4911fb2b2e6d From eu259473 at tele2.it Fri Mar 2 06:16:40 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 02 Mar 2007 14:16:40 +0100 Subject: [Rxtx] rxtx on HP tru 64 unix Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070302/706c7a70/attachment-0002.html From tjarvi at qbang.org Fri Mar 2 08:39:33 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 08:39:33 -0700 (MST) Subject: [Rxtx] rxtx on HP tru 64 unix In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, "Giuseppe Marchese" wrote: > Hi > > I try to install rxtx on hp tru 64 but make fails, > There are somebody that do the same and work. > > > Sorry for may english! > > Hi Giuseppe Could you provide a log of the failure? script ./configure make # use gnu make exit The information will be in the typescript created. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 2 19:56:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 19:56:52 -0700 (MST) Subject: [Rxtx] dynamic detect rs232 port In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, Wang Chinkai wrote: > Hi all > > I have a question about detecting rs232 port dynamicly. > > I have to aceess some port and detect rs232 port at the same time. > Some usb device simulates rs232 port , and I can not know > what the port name it gets until it connects,so I have to detect it > dynamic,but I have to access > another rs232 device at the same time. > > I found a problem. Hi Wang This is a known problem. The code is braindead there. In fact there needs to be events even in a rudamentary way when you add a usb dongle. I'm burried in tasks not far from rxtx but not in rxtx. I can't get to the problem but we would accept patches if you dig into it. [I'm getting to the license question earlier too; I don't have another 10%] -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Fri Mar 2 23:19:01 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 01:19:01 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Hi, Under ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable USB -> serial converter(using virtual com port drivers), with using example code pretty much straight out of http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port opens fine, enumerations all work, etc. My application calls for a large amount of data to be transferred in a short amount of time at 2,000,000 baud. My hardware sends approximately 15,232 bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL converter work fine, and the application works using C++. In C++, I do a hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); to open the port, and a boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); to read the port. The variable buffer fills with the 15238 bytes, and returns. If I do a resultz = is.read(cbuf,0,15238); in java with RXTX where is = new BufferedReader(new InputStreamReader(port.getInputStream())); and where resultz is an int, and cbuf is a char [] cbuf, resultz gets EXACTLY 3968 bytes the first time called. If I call it multiple times, I get roughly 11k total(less than what is sent), never more than the 3968 bytes per is.read() call. My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 bytes. I've played with inputbuffersize, receive threshold, receivetimeout, and so on. The FTDI virtual com port drivers that I'm using are rock solid, and have had zero problems with them using a variety of applications, some of my own, some professionally written, etc. No flow control is used anyplace, no RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. No exceptions are being thrown. What am I doing wrong, and what I can adjust to receive the full 15k bytes in one single read? Thanks! Keith From Eric.Arseneau at sun.com Fri Mar 2 23:32:07 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Fri, 02 Mar 2007 22:32:07 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <45E91667.20501@sun.com> This is the same type of thing that is happening to me on Mac OS X and does not seem to behave the same on different machines. I posted a day or two ago on this with subject "Mac OS X and missing data". Would love to hear if there is a solution to this :) From tjarvi at qbang.org Sat Mar 3 10:54:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 10:54:17 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > Hi, > > Under > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable > USB -> serial converter(using virtual com port drivers), with using example > code pretty much straight out of > http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port > opens fine, enumerations all work, etc. > > My application calls for a large amount of data to be transferred in a short > amount of time at 2,000,000 baud. My hardware sends approximately 15,232 > bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL > converter work fine, and the application works using C++. > > In C++, I do a > > hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, > OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); > > to open the port, and a > > boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); > > to read the port. > > The variable buffer fills with the 15238 bytes, and returns. > > If I do a > > resultz = is.read(cbuf,0,15238); in java with RXTX > > where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > > and where resultz is an int, and cbuf is a char [] cbuf, resultz gets > EXACTLY 3968 bytes the first time called. If I call it multiple times, I get > roughly 11k total(less than what is sent), never more than the 3968 bytes > per is.read() call. > > My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 > bytes. > > I've played with inputbuffersize, receive threshold, receivetimeout, and so > on. The FTDI virtual com port drivers that I'm using are rock solid, and > have had zero problems with them using a variety of applications, some of my > own, some professionally written, etc. No flow control is used anyplace, no > RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. > > No exceptions are being thrown. > > What am I doing wrong, and what I can adjust to receive the full 15k bytes > in one single read? > > Thanks! > Hi Keith I would expect a 20 meg application is going to have different behavior with the OS than a smaller application with respect to the kernel memory managment, schedualing, ... Something subtle could be causing problems. With respect to the recieve timeout and threshold, if you set the timeout to zero and the threshold to the size of data you expect, read should not return until it get that data. You may try with a stand alone application that tests just that with the C/C++ API. If the read is returning with less data when tested for short reads, you have found a bug in the device driver more than likely. The USB dongle vendor would probably be interested in knowing about this. As mentioned, these devices are getting very good; almost bug free. I suspect you found a bug though if you did use the threshold and timeout properly. The missing data is typical when not using flow control. When the OS buffering fills, the hardware will start dropping bytes. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:38:52 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:38:52 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> update: I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now instead of 3968. This makes sense. 128 bytes of overhead + 3968 bytes of data = 4096 transfer size 32 bytes of overhead + 992 bytes of data = 1024 transfer size. 1/4 the data = 1/4 the overhead. I rearranged my reading like so: resultz = is.read(cbuf,0,3968); resultz = is.read(cbuf,3968,3968); resultz = is.read(cbuf,7936,3968); while (!(is.ready())); // wait for ready resultz = is.read(cbuf,11904,3334); and this grabs 15,238 bytes total. BUT, I still have the quandry of the screwed up multi-bytes. I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. Approx 8% of the data. The bad bytes always seem to take the flavor of 0x2018, 0x2019, x2022, x2030, x201d. Are these maybe errors and I don't know what they enumerate to? I still can't believe some other layer isn't handling putting those bytes together all in one stream for me. Thanks Keith ----- Original Message ----- From: "Keith" To: "Bob Jacobsen" ; "RXTX Developers and Users" Sent: Saturday, March 03, 2007 11:26 AM Subject: Re: [Rxtx] is.read() only returning 3968 bytes > Bob, > > > Interesting numerical coincidence is that (max USB transfer) - (what > > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > > needed to transfer that much data. > > I was thinking along the same lines. I don't know USB well, but I do know > that those numbers were close enough to warrant investigating the > relationship between them. > > > I think what you're seeing is the internal buffering of the USB data > > stream. You'll need some form of higher-level buffering to smooth > > that out. > > Shouldn't the InputStreamReader() and BufferedReader() provide this type of > buffering? Isn't that the idea behind those? > > > All hypotheses need to be tested. In this case, a test would be to > > check for missing data. If this idea is right, you'll get _all_ the > > data, but you won't be missing characters. > > I did start looking at the data. -- I'm getting weird results. > > I tried this: > > loopzz = 0; > > for (looptwo = 0; looptwo < 100000; looptwo++) { > while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > > }} > > So I'm reading one character at a time. The good news is that loopzz is > exactly 15238 at the end of the routine, which is perfectly correct. I > picked looptwo value out of thin air. > > The weird results come in terms of the values, the data isn't correct at > least in one case. Look here: > > 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > > This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). > But the 0x89 was replaced by 0x2030. Why the heck would the returned value > be 0x2030?? Why is the returned byte completely out of range? Why the > multibyte return? > > From InputStream in the API: > > read > public abstract int read() > throws IOExceptionReads the next byte of data from the > input stream. The value byte is returned as an int in the range 0 to 255. If > no byte is available because the end of the stream has been reached, the > value -1 is returned. This method blocks until input data is available, the > end of the stream is detected, or an exception is thrown. > Value should be 0-255. > > > In my application time is really critical, reading 1 byte at a time is > probably not going to work. > > Thanks Eric & Bob for looking at this. > > Keith > From tjarvi at qbang.org Sat Mar 3 12:52:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 12:52:27 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > update: > > I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now > instead of 3968. > > This makes sense. > > 128 bytes of overhead + 3968 bytes of data = 4096 transfer size > 32 bytes of overhead + 992 bytes of data = 1024 transfer size. > > 1/4 the data = 1/4 the overhead. > > I rearranged my reading like so: > > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. > Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? > > I still can't believe some other layer isn't handling putting those bytes > together all in one stream for me. > The layer for this in Serial land is flow control. Software and hardware flow control prevent the overruns you observe. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:54:41 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:54:41 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <001a01c75dcd$c8802a70$6600a8c0@jbh757ktruws7g> Trent, Thanks for taking the time to reply. > I would expect a 20 meg application is going to have different behavior > with the OS than a smaller application with respect to the kernel memory > managment, schedualing, ... Something subtle could be causing problems. Well, at least I know the VCP drivers, the OS, etc can handle 2mbps reliably. Without hiccuping or dropping bytes. The C++ code works reliably without flow control. > The missing data is typical when not using flow control. When the OS > buffering fills, the hardware will start dropping bytes. I'm actually not getting MISSING data, I'm getting CORRUPTED data. If you look at my most recent post, I'm getting these bad bytes in place of the correct values: 0x2018, 0x2019, x2022, x2030, x201d. Why would is.read() return values not in the range of 0-255 ? Thanks. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 08:59:14 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 07:59:14 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: At 1:19 AM -0500 3/3/07, Keith wrote: >If I do a > >resultz = is.read(cbuf,0,15238); in java with RXTX > >where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > >and where resultz is an int, and cbuf is a char [] cbuf, resultz gets >EXACTLY 3968 bytes the first time called. If I call it multiple times, I get >roughly 11k total(less than what is sent), never more than the 3968 bytes >per is.read() call. > >My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 >bytes. Interesting numerical coincidence is that (max USB transfer) - (what you get) = 4096-3968 = 128 bytes is (almost) the size of the headers needed to transfer that much data. I think what you're seeing is the internal buffering of the USB data stream. You'll need some form of higher-level buffering to smooth that out. All hypotheses need to be tested. In this case, a test would be to check for missing data. If this idea is right, you'll get _all_ the data, but you won't be missing characters. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 09:26:14 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 11:26:14 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Bob, > Interesting numerical coincidence is that (max USB transfer) - (what > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > needed to transfer that much data. I was thinking along the same lines. I don't know USB well, but I do know that those numbers were close enough to warrant investigating the relationship between them. > I think what you're seeing is the internal buffering of the USB data > stream. You'll need some form of higher-level buffering to smooth > that out. Shouldn't the InputStreamReader() and BufferedReader() provide this type of buffering? Isn't that the idea behind those? > All hypotheses need to be tested. In this case, a test would be to > check for missing data. If this idea is right, you'll get _all_ the > data, but you won't be missing characters. I did start looking at the data. -- I'm getting weird results. I tried this: loopzz = 0; for (looptwo = 0; looptwo < 100000; looptwo++) { while (is.ready()) { cbuf[loopzz] = (char) is.read(); loopzz++; }} So I'm reading one character at a time. The good news is that loopzz is exactly 15238 at the end of the routine, which is perfectly correct. I picked looptwo value out of thin air. The weird results come in terms of the values, the data isn't correct at least in one case. Look here: 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). But the 0x89 was replaced by 0x2030. Why the heck would the returned value be 0x2030?? Why is the returned byte completely out of range? Why the multibyte return? >From InputStream in the API: read public abstract int read() throws IOExceptionReads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown. Value should be 0-255. In my application time is really critical, reading 1 byte at a time is probably not going to work. Thanks Eric & Bob for looking at this. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 14:44:50 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 13:44:50 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: Java's "char" type is Unicode. I think what you're seeing is a bug in the byte -> Unicode translation. 0x2018, 0x2019 are the curly open and close quotes. There used to be (and might still be) bugs in the conversion of these in a couple of libc versions. Some of the ASCII -> ISO and ISO -> ASCII routines were a little over-ambitious with respect to handling the open and close quotes, and tried to convert them to the "curly" form inappropriately. Try _not_ casting it to char. Bob At 11:26 AM -0500 3/3/07, Keith wrote: >Bob, > >> Interesting numerical coincidence is that (max USB transfer) - (what >> you get) = 4096-3968 = 128 bytes is (almost) the size of the headers >> needed to transfer that much data. > >I was thinking along the same lines. I don't know USB well, but I do know >that those numbers were close enough to warrant investigating the >relationship between them. > >> I think what you're seeing is the internal buffering of the USB data >> stream. You'll need some form of higher-level buffering to smooth >> that out. > >Shouldn't the InputStreamReader() and BufferedReader() provide this type of >buffering? Isn't that the idea behind those? > >> All hypotheses need to be tested. In this case, a test would be to >> check for missing data. If this idea is right, you'll get _all_ the >> data, but you won't be missing characters. > >I did start looking at the data. -- I'm getting weird results. > >I tried this: > >loopzz = 0; > >for (looptwo = 0; looptwo < 100000; looptwo++) { >while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > >}} > >So I'm reading one character at a time. The good news is that loopzz is >exactly 15238 at the end of the routine, which is perfectly correct. I >picked looptwo value out of thin air. > >The weird results come in terms of the values, the data isn't correct at >least in one case. Look here: > >0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > >This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). >But the 0x89 was replaced by 0x2030. Why the heck would the returned value >be 0x2030?? Why is the returned byte completely out of range? Why the >multibyte return? > >>From InputStream in the API: > >read >public abstract int read() > throws IOExceptionReads the next byte of data from the >input stream. The value byte is returned as an int in the range 0 to 255. If >no byte is available because the end of the stream has been reached, the >value -1 is returned. This method blocks until input data is available, the >end of the stream is detected, or an exception is thrown. >Value should be 0-255. > > >In my application time is really critical, reading 1 byte at a time is >probably not going to work. > >Thanks Eric & Bob for looking at this. > >Keith > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 15:10:11 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 17:10:11 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Bob said ..... > Java's "char" type is Unicode. I think what you're seeing is a bug > in the byte -> Unicode translation. Bob -- I think you hit the nail on the head. I was just coming to the same realization here. I knew that something funny was going on because the same bytes always got "corrupted." I'm pretty sure its in the InputStreamReader() functionality where the conversion junk is happening. Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. I don't know if simply changing the cast is going to work. Since the conversion is happening upstream (pun intended), I don't think my cast is doing this. Also I think the compiler forced me to use the cast. I'm still playing around, and I'll report back once I nail it down. Thanks!! Keith From tjarvi at qbang.org Sat Mar 3 15:59:46 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 15:59:46 -0700 (MST) Subject: [Rxtx] Win64 rxtx Testers? Message-ID: I have compiled win64 binaries of rxtx. Are there any users interested in testing them? If so, I'll look into putting them on the web site. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Mar 3 15:35:06 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 14:35:06 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: Because of this and similar problems, JMRI does all it's serial IO using +only+ byte values. It's a but of a pain, as Java wants to go to char and int types a little too aggressively, but it does solve the "uncontrolled conversions" problems. Bob At 5:10 PM -0500 3/3/07, Keith wrote: >Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > >Bob -- I think you hit the nail on the head. > >I was just coming to the same realization here. I knew that something funny >was going on because the same bytes always got "corrupted." > >I'm pretty sure its in the InputStreamReader() functionality where the >conversion junk is happening. > >Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > >I don't know if simply changing the cast is going to work. Since the >conversion is happening upstream (pun intended), I don't think my cast is >doing this. Also I think the compiler forced me to use the cast. -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mark at mdsh.com Sun Mar 4 11:01:33 2007 From: mark at mdsh.com (Mark Himsley) Date: Sun, 04 Mar 2007 18:01:33 +0000 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: <5C01AC72C200388815C04982@bedroom.mdsh.local> On 03 March 2007 14:38 -0500 Keith wrote: > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT > consistent. Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? It looks like you need to use DataInputStream and DataOutputStream. -- Mark Himsley From tjarvi at qbang.org Sun Mar 4 11:35:08 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 11:35:08 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" > > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > > * Line #21 - Not sure if you need a (TM) mark for > the term "Sun" > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > OK. I'm going through this today. Some groups ask if rxtx could be under their license also. I think this is a good example of why I resist multiple licenses and focus on why the current license may not be usable by them. The RXTX project is a convergence of hobby and commercial interests. I happen to do both right now. The problem with licensing is we have to stay on top of them as they change. Clearly, adding more licenses will not make this easier. I'm acting as the hobby person today. RXTX always favors the hobby people. But as we move forward, I'm going to need to bring this to lawyers at work and explain to them what is going on. Others here may have to do this also. I don't anticipate problems or unexpected changes. The goal is a consistant, comprehendable and usable license as close to what we have now as possible. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 14:52:10 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 14:52:10 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (1/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: I'm breaking this into two parts. I expect the second part will need more attention. Comments first, then the changed material below. On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > Thanks > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. OK. RXTX for consitent use. java should not be capitalized because it does not only mean Sun [TM] Java [TM]. An example of this not meaning Java is when people use RXTX with GCJ. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". There are not any contributors that are in all of RXTX yet but I did update the comment to try to reflect the current situation without making it a nightmare to maintain. I looked to see how the Linux kernel does it as a reference point. > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" The URL can be problematic. I have done so below with a time reference. GNU does not provide version information in their URLS. I picture this being a problem when the version 3 comes out. > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > This will be corrected when the copy is updated to the version linked below. ---------------- begin proposed material involved -------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. ----------------- end proposed material involved -------------------- I'll be looking at the linking issue again next. That should be all that remains other than including the 2.1 version. Let me know if you have problems with anything here. I do not want to dilute the material I post next with these housekeeping tasks. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 16:08:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 16:08:36 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: For those that are wondering what is going on here, this next bit is the meat of the changes. We agreed a long time ago to put this disclaimer in. We did a so so job. It was in rxtx 2.0, not well written, ... So some groups using rxtx that would like to ship rxtx so users don't need to download, install, go to the mail-list to find why it failed, ... Then their legal teams tell them section 5 paragraph 2 is a show stopper. That was never the intent. Now going through what remains... > and might need a (TM) suffix to make Sun happy. Added disclaimer at the ended 'all trademarks belong...' > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. OK. As you can see I was trying to adjust GNU text there for the LGPL. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. used dynamically linked terminology. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". I tried to address this more upfront with an intent statement. Let me know if you have problems with it. I also tried to make it a little more clear what was derived from the GNU solution by moving the link location closer to GNU's suggestion. > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > Thats the intent. Here is the combined fixes. Note that only the material in /*-- --*/ is being touched. The new GPL license is there but unmodified. ------------------------ begin proposed new license ------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. | | An executable that contains no derivative of any portion of RXTX, but | is designed to work with RXTX by being dynamically linked with it, | is considered a "work that uses the Library" subject to the terms and | conditions of the GNU Lesser General Public License. | | The following has been added to the RXTX License to remove | any confusion about linking to RXTX. We want to allow in part what | section 5, paragraph 2 of the LGPL does not permit in the special | case of linking over a controlled interface. The intent is to add a | Java Specification Request or standards body defined interface in the | future as another exception but one is not currently available. | | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface | | As a special exception, the copyright holders of RXTX give you | permission to link RXTX with independent modules that communicate with | RXTX solely through the Sun Microsytems CommAPI interface version 2, | regardless of the license terms of these independent modules, and to copy | and distribute the resulting combined work under terms of your choice, | provided that every copy of the combined work is accompanied by a complete | copy of the source code of RXTX (the version of RXTX used to produce the | combined work), being distributed under the terms of the GNU Lesser General | Public License plus this exception. An independent module is a | module which is not derived from or based on RXTX. | | Note that people who make modified versions of RXTX are not obligated | to grant this special exception for their modified versions; it is | their choice whether to do so. The GNU Lesser General Public License | gives permission to release a modified version without this exception; this | exception also makes it possible to release a modified version which | carries forward this exception. | | You should have received a copy of the GNU Lesser General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA | All trademarks belong to their respective owners. --------------------------------------------------------------------------*/ The original GNU Lesser General Public License Follows. GNU LESSER GENERAL PUBLIC LICENSE Version 2.1, February 1999 Copyright (C) 1991, 1999 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. [This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence the version number 2.1.] Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This license, the Lesser General Public License, applies to some specially designated software packages--typically libraries--of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below. When we speak of free software, we are referring to freedom of use, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish); that you receive source code or can get it if you want it; that you can change the software and use pieces of it in new free programs; and that you are informed that you can do these things. To protect your rights, we need to make restrictions that forbid distributors to deny you these rights or to ask you to surrender these rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library or if you modify it. For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights. We protect your rights with a two-step method: (1) we copyright the library, and (2) we offer you this license, which gives you legal permission to copy, distribute and/or modify the library. To protect each distributor, we want to make it very clear that there is no warranty for the free library. Also, if the library is modified by someone else and passed on, the recipients should know that what they have is not the original version, so that the original author's reputation will not be affected by problems that might be introduced by others. Finally, software patents pose a constant threat to the existence of any free program. We wish to make sure that a company cannot effectively restrict the users of a free program by obtaining a restrictive license from a patent holder. Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license. Most GNU software, including some libraries, is covered by the ordinary GNU General Public License. This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs. When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library. We call this license the "Lesser" General Public License because it does Less to protect the user's freedom than the ordinary General Public License. It also provides other free software developers Less of an advantage over competing non-free programs. These disadvantages are the reason we use the ordinary General Public License for many libraries. However, the Lesser license provides advantages in certain special circumstances. For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License. In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software. For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU operating system, as well as its variant, the GNU/Linux operating system. Although the Lesser General Public License is Less protective of the users' freedom, it does ensure that the user of a program that is linked with the Library has the freedom and the wherewithal to run that program using a modified version of the Library. The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, whereas the latter must be combined with the library in order to run. GNU LESSER GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License Agreement applies to any software library or other program which contains a notice placed by the copyright holder or other authorized party saying it may be distributed under the terms of this Lesser General Public License (also called "this License"). Each licensee is addressed as "you". A "library" means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables. The "Library", below, refers to any such software library or work which has been distributed under these terms. A "work based on the Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term "modification".) "Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library. Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does. 1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) The modified work must itself be a software library. b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change. c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License. d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful. (For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library. In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. 4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange. If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code. 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables. When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law. If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.) Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself. 6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications. You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things: a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.) b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. c) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution. d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place. e) Verify that the user has already received a copy of these materials or that you have already sent this user a copy. For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute. 7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things: a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above. b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work. 8. You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 9. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Library (or any work based on the Library), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Library or works based on it. 10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties with this License. 11. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply, and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 12. If the distribution and/or use of the Library is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Library under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 13. The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation. 14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Libraries If you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the ordinary General Public License). To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Also add information on how to contact you by electronic and paper mail. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the library, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the library `Frob' (a library for tweaking knobs) written by James Random Hacker. , 1 April 1990 Ty Coon, President of Vice That's all there is to it! ------------------------ end of proposed license ------------------ -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sun Mar 4 16:26:04 2007 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 04 Mar 2007 17:26:04 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <45EB558C.3010609@cox.net> Bob Jacobsen wrote: > Because of this and similar problems, JMRI does all it's serial IO > using +only+ byte values. It's a but of a pain, as Java wants to go > to char and int types a little too aggressively, but it does solve > the "uncontrolled conversions" problems. Anytime that you are reading bytes of data that is not printable, unicode text, in Java, you really need to stay away from the Readers. Use input stream only, or you will see unicode valued byte groups converted to unicode "char" values. Gregg Wonderly From joachim at buechse.de Mon Mar 5 04:23:48 2007 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 5 Mar 2007 12:23:48 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> The behaviour is exactly what you asked for in you code. is = new BufferedReader(new InputStreamReader(port.getInputStream())); Readers return Text (ie unicode chars) not bytes. You instantiate the InputStreamReader without saying which charset you want, which means "platform default". As this is on Windows, it will convert Windows characters to equivalent unicode characters. If you want to read bytes, read bytes not Text. Reading bytes is done with InputStream and BufferedInputStream. BTW: The InputStream and Reader methods that read arrays are not guarenteed to fill up the array. You always have to check what you really got, and advance your index accordingly. A typical "read up to 32k" method looks like this: InputStream is= ... // -- determine the max buffer size int len= is.available(); if (len == 0) { len= 32 * 1024; } // -- read all available data byte[] buffer= new byte[len]; int pos= 0; int read; do { read= is.read(buffer, pos, buffer.length - pos); pos= pos + read; } while (read != -1 && pos < buffer.length); Best regards, Joachim --- Joachim B?chse Phone: +41 44 500 2604 Buechse Consulting Hadlaubsteig 2 CH-8006 Z?rich On 03.03.2007, at 23:10, Keith wrote: > Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > > Bob -- I think you hit the nail on the head. > > I was just coming to the same realization here. I knew that > something funny > was going on because the same bytes always got "corrupted." > > I'm pretty sure its in the InputStreamReader() functionality where the > conversion junk is happening. > > Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > > I don't know if simply changing the cast is going to work. Since the > conversion is happening upstream (pun intended), I don't think my > cast is > doing this. Also I think the compiler forced me to use the cast. > > I'm still playing around, and I'll report back once I nail it down. > > Thanks!! > > Keith > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Mon Mar 5 07:25:46 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 05 Mar 2007 08:25:46 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> Message-ID: <45EC286A.8060608@cox.net> Joachim Buechse wrote: > BTW: The InputStream and Reader methods that read arrays are not > guarenteed to fill up the array. You always have to check what you > really got, and advance your index accordingly. A typical "read up to > 32k" method looks like this: > > InputStream is= ... > // -- determine the max buffer size > int len= is.available(); > if (len == 0) { > len= 32 * 1024; > } > // -- read all available data > byte[] buffer= new byte[len]; > int pos= 0; > int read; > do { > read= is.read(buffer, pos, buffer.length - pos); > pos= pos + read; > } while (read != -1 && pos < buffer.length); > My preferred structure is. byte arr[ len ]; int cnt; int off = 0; while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { off += cnt; } This keeps you from adding -1 to pos when the read returns -1. It also skips out when the read is 0 bytes which, is not a described EOF in InputStream java docs, but is a condition I want to be aware of. Gregg Wonderly From joachim at buechse.de Tue Mar 6 02:52:58 2007 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 6 Mar 2007 10:52:58 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <45EC286A.8060608@cox.net> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: The code I copied was from a file resource reader, it shouldn't really be applied to networking/external IO code. Mea culpa. However aborting when you get 0 from read is not always what you want either (you kind of indicated that already). Some unix java implementations will return 0 if the kernel read was aborted with EINTER, which is rarely the point where you want to abort your read - at least not without further checks. A "complete" solution always depends on the events you need to handle and the time the total read could take in reality. In some cases it's worth checking Thread.isInterrupted() in the loop, some code re-loops on 0 but only a limited number of times, some check a total timeout limit, etc... Best regards, Joachim On 05.03.2007, at 15:25, Gregg Wonderly wrote: > My preferred structure is. > > byte arr[ len ]; > int cnt; > int off = 0; > while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { > off += cnt; > } > > This keeps you from adding -1 to pos when the read returns -1. It > also skips > out when the read is 0 bytes which, is not a described EOF in > InputStream java > docs, but is a condition I want to be aware of. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Mar 6 14:47:44 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 Mar 2007 14:47:44 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: Just FYI, rxtx will usually not break out on EINTER. The code in the native library usually does something close to this: do { read(...) } while ( !done && errno==EINTR ); Obviously there is a little more involved but it will retry on EINTER if not done. On Tue, 6 Mar 2007, Joachim Buechse wrote: > The code I copied was from a file resource reader, it shouldn't > really be applied to networking/external IO code. Mea culpa. > > However aborting when you get 0 from read is not always what you want > either (you kind of indicated that already). Some unix java > implementations will return 0 if the kernel read was aborted with > EINTER, which is rarely the point where you want to abort your read - > at least not without further checks. A "complete" solution always > depends on the events you need to handle and the time the total read > could take in reality. In some cases it's worth checking > Thread.isInterrupted() in the loop, some code re-loops on 0 but only > a limited number of times, some check a total timeout limit, etc... > > Best regards, > Joachim > > On 05.03.2007, at 15:25, Gregg Wonderly wrote: >> My preferred structure is. >> >> byte arr[ len ]; >> int cnt; >> int off = 0; >> while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { >> off += cnt; >> } >> >> This keeps you from adding -1 to pos when the read returns -1. It >> also skips >> out when the read is 0 bytes which, is not a described EOF in >> InputStream java >> docs, but is a condition I want to be aware of. >> >> Gregg Wonderly >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 gjhanna at gmail.com Thu Mar 8 13:42:52 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Fri, 9 Mar 2007 09:42:52 +1300 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? Message-ID: I've just struck an issue using rxtx in a multi-threaded environment: If I have 3 threads trying to open *the same* comm-port I get a deadlock in CommPortIdentifier.open If I have just 2, it works fine - I get a PortInUseException which is nice and I can handle it. The 3 thread->deadlock thing is causing me issues. (Sample code below). This is from the java thread-dump Found one Java-level deadlock: ============================= "Thread-2": waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object ), which is held by "Thread-1" "Thread-1": waiting to lock monitor 0x0003e9cc (object 0x2450e108, a gnu.io.CommPortIdentifier), which is held by "Thread-2" Java stack information for the threads listed above: =================================================== "Thread-2": at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:329) - waiting to lock <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) "Thread-1": at java.lang.Object.wait(Native Method) - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) - locked <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) (Apart from this, rxtx is working fantastically for us). I'm thinking I'll have to implement some sort of locking mechanism that *doesn't* use java synchronization to prevent this situation. (Which doesn't sound like a good idea to me). Any ideas? Thanks, Greg Hanna ============= RXTXLockTest.java ======================================== import gnu.io.CommPort; import gnu.io.CommPortIdentifier; /** * @author Greg Hanna * Minimal code to create a deadlock with rxtx in multithreaded open */ public class RXTXLockTest { public static void main(String[] args) { try { CommPortIdentifier cpiCom1 = CommPortIdentifier.getPortIdentifier ("COM14"); OpenThread t1 = new OpenThread (" one ", cpiCom1); OpenThread t2 = new OpenThread (" two ", cpiCom1); OpenThread t3 = new OpenThread (" 003 ", cpiCom1); t1.start(); t2.start(); t3.start(); // comment this out and it runs with (expected) PortInUseException } catch (Exception e) { e.printStackTrace(); } } } class OpenThread extends Thread { String name; CommPortIdentifier cpi; CommPort cp; public OpenThread (String name, CommPortIdentifier cpi) { this.name = name; this.cpi = cpi; System.out.println (System.currentTimeMillis() + name + " thread created"); } public void run () { try { System.out.println (System.currentTimeMillis() + name + " opening"); cp = cpi.open(name, 2000); System.out.println (System.currentTimeMillis() + name + " opened - sleeping"); sleep (2000); // do the serial comms with the device. System.out.println (System.currentTimeMillis() + name + " slept - closing"); cp.close(); System.out.println (System.currentTimeMillis() + name + " closed - exiting"); } catch (Exception e) { System.out.println ("Error in thread: " + name ); e.printStackTrace(); } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070308/d9a163c5/attachment-0002.html From eu259473 at tele2.it Fri Mar 9 02:46:20 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 09 Mar 2007 10:46:20 +0100 Subject: [Rxtx] rxtx: tru64 unix make fails Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070309/3b654523/attachment-0002.html From lyon at docjava.com Fri Mar 9 03:58:32 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 Mar 2007 05:58:32 -0500 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi All, The deadlock issue is one that I have been thinking about for some time now. It seems to me that we need a resource manager that enables assignment to a known process. The one thing that seems important about serial ports is that two applications should not use the same serial port at the same time. When this happens, it throws an exception. OK. The exception is a response to a lock condition that arises from an unavailable resource. An abstract implementation (not born of native methods) might assign a serial port to an application, until the application releases it (or is forced to release it by some kill mechanism). Some resources (like a registry) can be reused. But others, like the serial port, cannot. In the case of the serial port, we would like, I think, to have the flyweight design pattern without sharing and with object assignment tracking. A means of breaking deadlock (like a leasing mechanism) seems very useful, to me. My guess is that we can serialize the state of the Parametric Singleton Pattern (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) into the Preferences of the System. Preferences.systemRoot() might help with that. When a resource is checked out, the lease time and owner are listed. A thread that does this can be killed, but applications outside of Java are problematic. There is a compelling problem here. It is not just serial ports. Sound cards, cameras, microphones, files, tape drives, etc. All are consumed resources that are assigned to an application (or user) and deprive other applications, or users, from use. What, if anything, should we do? At present we throw PortInUseExceptions. Is that it? Can we do better? OK, the port is in use. Now what? Do I have to be root to go remove lock files and kill applications? Is there a better way? Thanks! - Doug >I've just struck an issue using rxtx in a multi-threaded environment: > >If I have 3 threads trying to open *the same* >comm-port I get a deadlock in >CommPortIdentifier.open >If I have just 2, it works fine - I get a >PortInUseException which is nice and I can >handle it. > >The 3 thread->deadlock thing is causing me issues. >(Sample code below). > >This is from the java thread-dump > >Found one Java-level deadlock: >============================= >"Thread-2": > waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), > which is held by "Thread-1" >"Thread-1": > waiting to lock monitor 0x0003e9cc (object >0x2450e108, a gnu.io.CommPortIdentifier ), > which is held by "Thread-2" > >Java stack information for the threads listed above: >=================================================== >"Thread-2": > at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) > - waiting to lock <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) >"Thread-1": > at java.lang.Object.wait(Native Method) > - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) > - locked <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) > > >(Apart from this, rxtx is working fantastically for us). > >I'm thinking I'll have to implement some sort of >locking mechanism that *doesn't* use java >synchronization to prevent this situation. >(Which doesn't sound like a good idea to me). > >Any ideas? > >Thanks, > >Greg Hanna > >============= RXTXLockTest.java ======================================== > >import gnu.io.CommPort; >import gnu.io.CommPortIdentifier; > >/** > * @author Greg Hanna > * Minimal code to create a deadlock with rxtx in multithreaded open > */ >public class RXTXLockTest { > ? > ?public static void main(String[] args) { > ?try { > ?CommPortIdentifier cpiCom1 = >CommPortIdentifier.getPortIdentifier ("COM14"); > ?OpenThread t1 = new OpenThread (" one ", cpiCom1); > ?OpenThread t2 = new OpenThread (" two ", cpiCom1); > ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); > ?t1.start(); > ?t2.start(); > ?t3.start(); // comment this out >and it runs with (expected) PortInUseException > ?} catch (Exception e) { > ?e.printStackTrace(); > ?} > ?} >} > >class OpenThread extends Thread { > ?String name; > ?CommPortIdentifier cpi; > ?CommPort cp; > ?public OpenThread (String name, CommPortIdentifier cpi) { > ? this.name = name; > ?this.cpi = cpi; > ?System.out.println >(System.currentTimeMillis() + name + " thread >created"); > ?} > ?public void run () { > ?try { > ?System.out.println >(System.currentTimeMillis() + name + " opening"); > ?cp = cpi.open(name, 2000); > ?System.out.println >(System.currentTimeMillis() + name + " opened - >sleeping"); > ?sleep (2000); // do the serial comms with the device. > ?System.out.println >(System.currentTimeMillis() + name + " slept - >closing"); > ?cp.close(); > ?System.out.println >(System.currentTimeMillis() + name + " closed - >exiting"); > ?} catch (Exception e) { > System.out.println ("Error in thread: " + name ); > ?e.printStackTrace(); > ?} > ?} >} > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Mar 9 06:37:45 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 Mar 2007 06:37:45 -0700 (MST) Subject: [Rxtx] rxtx: tru64 unix make fails In-Reply-To: References: Message-ID: On Fri, 9 Mar 2007, "Giuseppe Marchese" wrote: > Sorry for delay. > ? > This is log for ./configure and make > error. > ? > thanks for attention > ? > Make: '%.java,$(TOP)/$(CLASSDEST)/%.class,$(wildcard $(SPATH)/*.java)': extra chars.? > Stop. > Hi Giuseppe You need to use GNU make with the Makefile. I suspect the tru64 make is not happy with those rules. > configure: exit 0 Looks like configure is fairly happy. From tjarvi at qbang.org Sat Mar 10 07:43:51 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 07:43:51 -0700 (MST) Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi Doug I have very little time to look into this further but what we could do is open up an rxtx 3 devel branch in which a proof of concept could be worked on. It could be the proof of concept for a JSR others including Sun could look at/work on or parts of it could be recycled in a JSR. I'm working very hard on rxtx right now but it does not show. I'm looking at win64, mac intel/ppc, usb bluetooth and usb serial dongles. Some are going to be more tested than others but they are all on the plate. I'll be pushing all the fixes upstream when they are done. So I'm very busy in 2.1 but we could open a new branch. On Fri, 9 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > The deadlock issue is one that I have been thinking about > for some time now. > It seems to me that we need a resource manager that enables assignment > to a known process. > > The one thing that seems important about serial > ports is that two applications should not use the > same serial port at the same time. When this > happens, it throws an exception. > OK. > > The exception is a response to a lock condition that > arises from an unavailable resource. > > An abstract implementation (not born of native methods) might > assign a serial port to an application, until the > application releases it (or is forced to release > it by some kill mechanism). > > Some resources (like a registry) can be reused. > But others, like the serial port, > cannot. > > In the case of the serial port, we would like, I think, to > have the flyweight design pattern > without sharing and with object assignment tracking. > A means of breaking deadlock (like a leasing > mechanism) seems very useful, to me. > > My guess is that we can serialize the state of the Parametric Singleton Pattern > (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) > into the Preferences of the System. Preferences.systemRoot() might help > with that. When a resource is checked out, the lease time and owner are > listed. A thread that does this can be killed, but applications outside of Java > are problematic. > > There is a compelling problem here. It is not just serial ports. > Sound cards, cameras, microphones, files, tape drives, etc. All are consumed > resources that are assigned to an application (or > user) and deprive other applications, > or users, from use. > > What, if anything, should we do? At present we throw PortInUseExceptions. > Is that it? > Can we do better? > OK, the port is in use. Now what? > Do I have to be root to go remove lock files and kill applications? > Is there a better way? > > Thanks! > - Doug > >> I've just struck an issue using rxtx in a multi-threaded environment: >> >> If I have 3 threads trying to open *the same* >> comm-port I get a deadlock in >> CommPortIdentifier.open >> If I have just 2, it works fine - I get a >> PortInUseException which is nice and I can >> handle it. >> >> The 3 thread->deadlock thing is causing me issues. >> (Sample code below). >> >> This is from the java thread-dump >> >> Found one Java-level deadlock: >> ============================= >> "Thread-2": >> waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), >> which is held by "Thread-1" >> "Thread-1": >> waiting to lock monitor 0x0003e9cc (object >> 0x2450e108, a gnu.io.CommPortIdentifier ), >> which is held by "Thread-2" >> >> Java stack information for the threads listed above: >> =================================================== >> "Thread-2": >> at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) >> - waiting to lock <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> "Thread-1": >> at java.lang.Object.wait(Native Method) >> - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) >> - locked <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> >> >> (Apart from this, rxtx is working fantastically for us). >> >> I'm thinking I'll have to implement some sort of >> locking mechanism that *doesn't* use java >> synchronization to prevent this situation. >> (Which doesn't sound like a good idea to me). >> >> Any ideas? >> >> Thanks, >> >> Greg Hanna >> >> ============= RXTXLockTest.java ======================================== >> >> import gnu.io.CommPort; >> import gnu.io.CommPortIdentifier; >> >> /** >> * @author Greg Hanna >> * Minimal code to create a deadlock with rxtx in multithreaded open >> */ >> public class RXTXLockTest { >> ? >> ?public static void main(String[] args) { >> ?try { >> ?CommPortIdentifier cpiCom1 = >> CommPortIdentifier.getPortIdentifier ("COM14"); >> ?OpenThread t1 = new OpenThread (" one ", cpiCom1); >> ?OpenThread t2 = new OpenThread (" two ", cpiCom1); >> ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); >> ?t1.start(); >> ?t2.start(); >> ?t3.start(); // comment this out >> and it runs with (expected) PortInUseException >> ?} catch (Exception e) { >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> class OpenThread extends Thread { >> ?String name; >> ?CommPortIdentifier cpi; >> ?CommPort cp; >> ?public OpenThread (String name, CommPortIdentifier cpi) { >> ? this.name = name; >> ?this.cpi = cpi; >> ?System.out.println >> (System.currentTimeMillis() + name + " thread >> created"); >> ?} >> ?public void run () { >> ?try { >> ?System.out.println >> (System.currentTimeMillis() + name + " opening"); >> ?cp = cpi.open(name, 2000); >> ?System.out.println >> (System.currentTimeMillis() + name + " opened - >> sleeping"); >> ?sleep (2000); // do the serial comms with the device. >> ?System.out.println >> (System.currentTimeMillis() + name + " slept - >> closing"); >> ?cp.close(); >> ?System.out.println >> (System.currentTimeMillis() + name + " closed - >> exiting"); >> ?} catch (Exception e) { >> System.out.println ("Error in thread: " + name ); >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 mm at UDel.Edu Sat Mar 10 14:48:32 2007 From: mm at UDel.Edu (Mike Markowski) Date: Sat, 10 Mar 2007 16:48:32 -0500 Subject: [Rxtx] rxtx and Sun's comm api Message-ID: <45F327B0.2060004@udel.edu> Hi all, I joined the list a few days ago and apologize for what is likely a frequently asked question, though I haven't yet found it anywhere. I learned about rxtx.org through the readme on Sun's version 2 of their comms api. They give recommendations in that readme regarding how a better comms api should be written. Is this the aim of rxtx.org? I wrote an app on my linux box using the Sun comms api (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the fact that only linux and Solaris are supported. So I'm glad to find rxtx.org and am just reading up on how make the conversion so Windows users will be able to run the program as well. At the same time I'm just curious if rxtx.org and Sun are both heading in the same direction. Thanks for any background or historical info. Feel free to point me to any www pages if my googling has just completely missed the target! Thanks again, Mike From tjarvi at qbang.org Sat Mar 10 15:35:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 15:35:25 -0700 (MST) Subject: [Rxtx] rxtx and Sun's comm api In-Reply-To: <45F327B0.2060004@udel.edu> References: <45F327B0.2060004@udel.edu> Message-ID: On Sat, 10 Mar 2007, Mike Markowski wrote: > Hi all, > > I joined the list a few days ago and apologize for what is likely a > frequently asked question, though I haven't yet found it anywhere. I > learned about rxtx.org through the readme on Sun's version 2 of their > comms api. They give recommendations in that readme regarding how a > better comms api should be written. Is this the aim of rxtx.org? > > I wrote an app on my linux box using the Sun comms api > (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the > fact that only linux and Solaris are supported. So I'm glad to find > rxtx.org and am just reading up on how make the conversion so Windows > users will be able to run the program as well. At the same time I'm > just curious if rxtx.org and Sun are both heading in the same direction. > > Thanks for any background or historical info. Feel free to point me to > any www pages if my googling has just completely missed the target! > I do not have any news (good or bad) concerning RXTX and Sun working together but perhaps others here do. The main goal of RXTX is to expose POSIX termios interfaces to java users. The future support of javax.comm is questionable. We do not have resources for everything. gnu.io (RXTX 2.1) will be supported going forward and functions the same as CommAPI 2.0. If you have control of the source code you are working with, I would not advise using CommAPI 2.0 javax.comm. We do support CommAPI 2.0 javax.comm for older applications but I do not think that will last much longer for practical reasons. The download interest in CommAPI 2.0 javax.comm support is becomming negligible on this end. There has been discussion of a JSR effort but I do not know of any status change since it was mentioned. One problem with a JSR is that even a light weight process is going to be difficult for RXTX at this time. Maybe that will change in the future but then again it may not. For now, we are just going forward 'as is' in rxtx 2.1 with package gnu.io while trying as a secondary effort to backport the changes to rxtx 2.0 for javax.comm support for users that do not have a choice. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Mar 11 07:19:40 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 11 Mar 2007 08:19:40 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: Hi All, I have been a proponent of a JSR that makes use of RXTX. I have executed the proper agreements with Sun. At this point we are in the: Early Draft Review of Draft Specifications Stage. The best thing to do is to enter the quiet period and create a specification. The question of exactly how we, as a group, want to approach this problem, remains open. Typically, we should have both a specification and a reference implementation. Thus, it would be to our best advantage to have a nice, stable, cross platform RXTX distro that adheres to the groups specification. Now, from a specification standpoint, my personal view on the matter is that we create a series of interfaces, with nice documentation (or at least javadoc). Is this a good idea? Should we have a pure interface specification for the communication API? There are several issues, in my mind, which still weigh on us. Hot-pluggable dongles, long discovery process on pop-up ports, lack of uniformity on device names, lack of uniformity on locking, a precise understanding of how the SerialPortResourceManager works (or even if we should have one). The more questions we answer in our reference implementation, the better our specification will get. RXTX is a good working prototype, but, I don't know if that is what we want to use for a specification. Here is what I have for a CommPortInterface: */ public interface CommPortInterface { /** * @return a string representation of this port. */ String toString(); /** * Gets the name of the communications port. This name should correspond to * something the user can identify, like the label on the hardware. * @return name of the port */ String getName(); /** * @return an input stream that can be used to read data from the * communications port. If the port doesn't support reading data, this * method returns null. *

* The blocking behaviour of this input stream depends on the threshold * and timeout values, as shown below for a read buffer size of n * bytes: * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ThresholdTimeoutBlocking behaviour
StateValueStateValue
disableddisabledblock until data is available
enabledm bytesdisabledblock until min(m, n) bytes are available
disabledenabledt msblock for t ms or until data is available
enabledm bytesenabledt msblock for t ms or until min(m, n) bytes are * available
* @throws java.io.IOException */ InputStream getInputStream() throws IOException; /** * @return an output stream that can be used to send data to the * communications port. If the port doesn't support sending data, this * method returns null. * @throws java.io.IOException */ OutputStream getOutputStream() throws IOException; /** * Closes this communications port. * All PortOwnershipListeners will be? * notified of this change of ownership. Further method calls on this? * object will throw IllegalStateException. Further calls on the? * associated InputStream or OutputStream will throw IOException. *

* Close does not block. Undelivered data is discarded. Blocked read and? * write operations are aborted if the underlying operating systems? * supports an IO abort mechanism. To await the delivery of undelivered? * data call OutputStream.flush() or OutputStream.close() before calling? * Port.close(). */ void close(); /** * Enables receive threshold. * When the specified threshold number of bytes are retrieved, read will * return immediately. * * @param thresh the number of bytes in the input buffer * @throws gnu.io.UnsupportedCommOperationException * if receive threshold is * not supported by the driver * @see #disableReceiveThreshold */ void enableReceiveThreshold(int thresh) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive threshold. * * @see #enableReceiveThreshold */ void disableReceiveThreshold(); /** * @return true if receive threshold is enabled. * * @see #enableReceiveThreshold */ boolean isReceiveThresholdEnabled(); /** * @return the receive threshold value. If receive threshold is diabled * or not supported, this value is meaningless. * * @see #enableReceiveThreshold */ int getReceiveThreshold(); /** * Enables receive timeout. * When the specified number of milliseconds have elapsed, read will * return immediately. * * @param rcvTimeout the number of milliseconds to block for * @throws gnu.io.UnsupportedCommOperationException * if receive timeout is * not supported by the driver * @see #disableReceiveTimeout */ void enableReceiveTimeout(int rcvTimeout) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive timeout. * * @see #enableReceiveTimeout */ void disableReceiveTimeout(); /** * @return true if receive timeout is enabled. * * @see #enableReceiveTimeout */ boolean isReceiveTimeoutEnabled(); /** * @return the receive timeout value. If receive timeout is diabled * or not supported, this value is meaningless. * * @see #enableReceiveTimeout */ int getReceiveTimeout(); /** * Enables receive framing. * The supplied byte value in the input suggests the end of the received * frame, and read returns immediately. Only the low 8 bits of the * supplied value are significant. * * @param framingByte the frame delimiter * @throws gnu.io.UnsupportedCommOperationException * if receive framing is * not supported by the driver * @see #disableReceiveFraming */ void enableReceiveFraming(int framingByte) throws UnsupportedCommOperationException; /** * Disables receive framing. * * @see #enableReceiveFraming */ void disableReceiveFraming(); /** * @return true if receive framing is enabled. * * @see #enableReceiveFraming */ boolean isReceiveFramingEnabled(); /** * @return true if receive framing byte. If receive framing is diabled * or not supported, this value is meaningless. * * @see #enableReceiveFraming */ int getReceiveFramingByte(); /** * Sets the input buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setInputBufferSize(int size); /** * @return the input buffer size. * The driver may choose not to report correct values. */ int getInputBufferSize(); /** * Sets the output buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setOutputBufferSize(int size); /** * @return the output buffer size. * The driver may choose not to report correct values. */ int getOutputBufferSize(); } What do you think of that? Note the wishy washy nature of the spec: The driver may choose to ignore this method. Is that good enough for us? Thanks! - Doug From ra85551 at gmail.com Sun Mar 11 08:44:45 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Sun, 11 Mar 2007 17:44:45 +0300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hello, world! I am writing application that communicates with modem via AT commands. My OS is Linux Kubuntu Feisty Herd, to ensure that my application will run properly under Windows XP I installed VMWare server. When I tried to send AT command and evaluate modem answer under WinXP @ VMWare server, I actually didn't receive anything. I think that VM settings are right, because I do can communicate with modem by using standard HyperTerminall as well as I can do on native Windows. So, why RXTX doesn't work under VM, but works under Linux and pure Windows XP (i tested it there) well? The send/receive method code follows. private String sendATCommand(String command, final String waitFor, final boolean isRegex, boolean isAddCRLF, long timeout) throws BeaconConnectException { final long POLL_PERIOD = 100; final int BUFFER_SIZE = 512; final byte[] buffer = new byte[BUFFER_SIZE]; final InputStream serialInput; final OutputStream serialOutput; try { serialInput = serialPort.getInputStream(); if (command != null) { serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } } catch (IOException e) { throw new MyException("serial I/O error"); } TimerTask task = new TimerTask() { int offset = 0; int bytesRead; public synchronized void run() { try { if (serialInput.available() > 0) { bytesRead = serialInput.read(buffer, offset, BUFFER_SIZE - offset); } else { return; } } catch (IOException e) { // do nothing - maybe next time we'll read something } offset += bytesRead; if (waitFor != null) { String temporary = new String(buffer, 0, offset).trim(); if (isRegex && temporary.matches(waitFor) || temporary.contains(waitFor)) { cancel(); notify(); } } } }; Timer timer = new Timer(); timer.schedule(task, POLL_PERIOD, POLL_PERIOD); synchronized (task) { try { task.wait(timeout); task.cancel(); } catch (InterruptedException e) { } } //Cut off leading and trailing CRs, LFs and zeroes String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); System.out.println(response); return response; } -- Pavel Parkhomenko From tjarvi at qbang.org Sun Mar 11 11:48:22 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:48:22 -0600 (MDT) Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: On Sun, 11 Mar 2007, Pavel Parkhomenko wrote: > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. > > private String sendATCommand(String command, final String waitFor, > final boolean isRegex, boolean isAddCRLF, long timeout) > throws BeaconConnectException > { > final long POLL_PERIOD = 100; > final int BUFFER_SIZE = 512; > final byte[] buffer = new byte[BUFFER_SIZE]; > final InputStream serialInput; > final OutputStream serialOutput; > try > { > serialInput = serialPort.getInputStream(); > if (command != null) > { > serialOutput = serialPort.getOutputStream(); > if (isAddCRLF) > { > command += "\r\n"; > } > System.out.println(command); > serialOutput.write(command.getBytes()); > } > } > catch (IOException e) > { > throw new MyException("serial I/O error"); > } > > TimerTask task = new TimerTask() > { > int offset = 0; > int bytesRead; > public synchronized void run() > { > try > { > if (serialInput.available() > 0) > { > bytesRead = serialInput.read(buffer, offset, > BUFFER_SIZE - offset); > } > else > { > return; > } > } > catch (IOException e) > { > // do nothing - maybe next time we'll read something > } > offset += bytesRead; > if (waitFor != null) > { > String temporary = new String(buffer, 0, offset).trim(); > if (isRegex && temporary.matches(waitFor) || > temporary.contains(waitFor)) > { > cancel(); > notify(); > } > } > } > }; > > Timer timer = new Timer(); > timer.schedule(task, POLL_PERIOD, POLL_PERIOD); > synchronized (task) { > try > { > task.wait(timeout); > task.cancel(); > } > catch (InterruptedException e) > { > } > } > //Cut off leading and trailing CRs, LFs and zeroes > String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); > System.out.println(response); > return response; > } > > > Hi Pavel VMWare should not be a problem. I've used it in the past - though not with a modem. Make sure nothing else is using the modem. Then look in the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an example that should work. Note that modems could care less what OS is on top. If you are trying to match new lines to the OS and sending it to the mode for AT commands, thats probably a mistake. Also it would not hurt to print out the individual bytes that you are sending to make sure they did not get mangled along the path. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 11:55:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:55:48 -0600 (MDT) Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: On Sun, 11 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > I have been a proponent of a JSR that makes > use of RXTX. I have executed the proper agreements with Sun. > > At this point we are in the: > Early Draft Review of Draft Specifications Stage. > > The best thing to do is to enter the quiet period and create > a specification. The question of exactly how we, as a group, > want to approach this problem, remains open. > > Typically, we should have both a specification and a reference > implementation. Thus, it would be to our best advantage to have > a nice, stable, cross platform RXTX distro that adheres to the > groups specification. > > Now, from a specification standpoint, my personal view on the matter is > that we create a series of interfaces, with nice documentation (or at least > javadoc). > > Is this a good idea? Should we have a pure interface specification for > the communication API? > > There are several issues, in my mind, which still weigh on us. > Hot-pluggable dongles, long discovery process on pop-up ports, > lack of uniformity on device names, lack of uniformity on locking, > a precise understanding of how the SerialPortResourceManager > works (or even if we should have one). > > The more questions we answer in our reference implementation, the > better our specification will get. RXTX is a good working prototype, > but, I don't know if that is what we want to use for a specification. > > Here is what I have for a CommPortInterface: > */ > public interface CommPortInterface { Hi Doug, I can start going through the method interfaces later this week and giving feedback. I would suggest that the JSR should not be too generic in nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel drivers that intend to look like EIA232 ports at the kernel driver level. some ideas: EIA232PortInterface TermiosInterface SerialPortInterface Something that differentiates this from thing like USB, I2C, ... which should not have to deal with legacy serial claiming to be the comm api. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 12:52:19 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 12:52:19 -0600 (MDT) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: No news is good news with these posts. I'll start the process of pinging legal a week from Monday on my end if nobody has objections to the proposal. I just want to make sure everyone has time to raise objections. Obviously, anyone can fork from a previous version if they don't like the new license. I suspect we can avoid that though. On Sun, 4 Mar 2007, Trent Jarvi wrote: > > For those that are wondering what is going on here, this > next bit is the meat of the changes. We agreed a long time > ago to put this disclaimer in. We did a so so job. It was > in rxtx 2.0, not well written, ... So some groups using > rxtx that would like to ship rxtx so users don't need to > download, install, go to the mail-list to find why it failed, > ... Then their legal teams tell them section 5 paragraph 2 > is a show stopper. > > That was never the intent. > > > Now going through what remains... > >> and might need a (TM) suffix to make Sun happy. > > Added disclaimer at the ended 'all trademarks belong...' > >> * Line #15ff - static vs. dynamic linking - you did >> not transcribe the text from the "controlled >> interface exception" when writing this text - and >> this was good so, because these terms originally >> refer to the GPL rather than the LGPL. I think though, >> that these 4 lines are the most important ones and >> should thus be really really clear. I hope that I >> meet your original intent with the following >> suggestions: >> 1.) Instead of "A program.." it would be better to >> say "An exectuable.." in order to be closer to >> the LGPL text. > > OK. As you can see I was trying to adjust GNU text there > for the LGPL. > >> 2.) It would be better to say .. "by being dynamically >> linked with it" to clearly indicate that dynamic >> linking is meant. The matter of compilation is >> already covered by the LGPL so mentioning it again >> just leads to confusion. > > used dynamically linked terminology. > >> 3.) It would be better to say .. "is considered a >> work that uses the library in contrast to section >> 5 of the LGPL, so the terms of the LGPL do not >> apply to the resulting executable". > > I tried to address this more upfront with an intent statement. > Let me know if you have problems with it. I also tried to > make it a little more clear what was derived from the GNU > solution by moving the link location closer to GNU's suggestion. > >> >> Note that LGPL section 5 says: ..."is called a >> "work that uses the Library". Such a work, in isolation, >> is not a derivative work of the Library, and therefore >> falls outside the scope of this License." >> The next paragraph of the LGPL is exactly the problematic >> one that I hope is clarified by the exception terms you >> give. >> > > Thats the intent. Here is the combined fixes. Note that only the > material in /*-- --*/ is being touched. The new GPL license is > there but unmodified. > > > ------------------------ begin proposed new license ------------------- > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Lesser General Public > | License as published by the Free Software Foundation; either > | version 2.1 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Lesser General Public License for more details. > | > | An executable that contains no derivative of any portion of RXTX, but > | is designed to work with RXTX by being dynamically linked with it, > | is considered a "work that uses the Library" subject to the terms and > | conditions of the GNU Lesser General Public License. > | > | The following has been added to the RXTX License to remove > | any confusion about linking to RXTX. We want to allow in part what > | section 5, paragraph 2 of the LGPL does not permit in the special > | case of linking over a controlled interface. The intent is to add a > | Java Specification Request or standards body defined interface in the > | future as another exception but one is not currently available. > | > | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface > | > | As a special exception, the copyright holders of RXTX give you > | permission to link RXTX with independent modules that communicate with > | RXTX solely through the Sun Microsytems CommAPI interface version 2, > | regardless of the license terms of these independent modules, and to copy > | and distribute the resulting combined work under terms of your choice, > | provided that every copy of the combined work is accompanied by a complete > | copy of the source code of RXTX (the version of RXTX used to produce the > | combined work), being distributed under the terms of the GNU Lesser General > | Public License plus this exception. An independent module is a > | module which is not derived from or based on RXTX. > | > | Note that people who make modified versions of RXTX are not obligated > | to grant this special exception for their modified versions; it is > | their choice whether to do so. The GNU Lesser General Public License > | gives permission to release a modified version without this exception; this > | exception also makes it possible to release a modified version which > | carries forward this exception. > | > | You should have received a copy of the GNU Lesser General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > | All trademarks belong to their respective owners. > --------------------------------------------------------------------------*/ > > The original GNU Lesser General Public License Follows. > > > GNU LESSER GENERAL PUBLIC LICENSE > Version 2.1, February 1999 > > Copyright (C) 1991, 1999 Free Software Foundation, Inc. > 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > Everyone is permitted to copy and distribute verbatim copies > of this license document, but changing it is not allowed. > > [This is the first released version of the Lesser GPL. It also counts > as the successor of the GNU Library Public License, version 2, hence > the version number 2.1.] > > Preamble > > The licenses for most software are designed to take away your > freedom to share and change it. By contrast, the GNU General Public > Licenses are intended to guarantee your freedom to share and change > free software--to make sure the software is free for all its users. > > This license, the Lesser General Public License, applies to some > specially designated software packages--typically libraries--of the > Free Software Foundation and other authors who decide to use it. You > can use it too, but we suggest you first think carefully about whether > this license or the ordinary General Public License is the better > strategy to use in any particular case, based on the explanations below. > > When we speak of free software, we are referring to freedom of use, > not price. Our General Public Licenses are designed to make sure that > you have the freedom to distribute copies of free software (and charge > for this service if you wish); that you receive source code or can get > it if you want it; that you can change the software and use pieces of > it in new free programs; and that you are informed that you can do > these things. > > To protect your rights, we need to make restrictions that forbid > distributors to deny you these rights or to ask you to surrender these > rights. These restrictions translate to certain responsibilities for > you if you distribute copies of the library or if you modify it. > > For example, if you distribute copies of the library, whether gratis > or for a fee, you must give the recipients all the rights that we gave > you. You must make sure that they, too, receive or can get the source > code. If you link other code with the library, you must provide > complete object files to the recipients, so that they can relink them > with the library after making changes to the library and recompiling > it. And you must show them these terms so they know their rights. > > We protect your rights with a two-step method: (1) we copyright the > library, and (2) we offer you this license, which gives you legal > permission to copy, distribute and/or modify the library. > > To protect each distributor, we want to make it very clear that > there is no warranty for the free library. Also, if the library is > modified by someone else and passed on, the recipients should know > that what they have is not the original version, so that the original > author's reputation will not be affected by problems that might be > introduced by others. > > Finally, software patents pose a constant threat to the existence of > any free program. We wish to make sure that a company cannot > effectively restrict the users of a free program by obtaining a > restrictive license from a patent holder. Therefore, we insist that > any patent license obtained for a version of the library must be > consistent with the full freedom of use specified in this license. > > Most GNU software, including some libraries, is covered by the > ordinary GNU General Public License. This license, the GNU Lesser > General Public License, applies to certain designated libraries, and > is quite different from the ordinary General Public License. We use > this license for certain libraries in order to permit linking those > libraries into non-free programs. > > When a program is linked with a library, whether statically or using > a shared library, the combination of the two is legally speaking a > combined work, a derivative of the original library. The ordinary > General Public License therefore permits such linking only if the > entire combination fits its criteria of freedom. The Lesser General > Public License permits more lax criteria for linking other code with > the library. > > We call this license the "Lesser" General Public License because it > does Less to protect the user's freedom than the ordinary General > Public License. It also provides other free software developers Less > of an advantage over competing non-free programs. These disadvantages > are the reason we use the ordinary General Public License for many > libraries. However, the Lesser license provides advantages in certain > special circumstances. > > For example, on rare occasions, there may be a special need to > encourage the widest possible use of a certain library, so that it becomes > a de-facto standard. To achieve this, non-free programs must be > allowed to use the library. A more frequent case is that a free > library does the same job as widely used non-free libraries. In this > case, there is little to gain by limiting the free library to free > software only, so we use the Lesser General Public License. > > In other cases, permission to use a particular library in non-free > programs enables a greater number of people to use a large body of > free software. For example, permission to use the GNU C Library in > non-free programs enables many more people to use the whole GNU > operating system, as well as its variant, the GNU/Linux operating > system. > > Although the Lesser General Public License is Less protective of the > users' freedom, it does ensure that the user of a program that is > linked with the Library has the freedom and the wherewithal to run > that program using a modified version of the Library. > > The precise terms and conditions for copying, distribution and > modification follow. Pay close attention to the difference between a > "work based on the library" and a "work that uses the library". The > former contains code derived from the library, whereas the latter must > be combined with the library in order to run. > > GNU LESSER GENERAL PUBLIC LICENSE > TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION > > 0. This License Agreement applies to any software library or other > program which contains a notice placed by the copyright holder or > other authorized party saying it may be distributed under the terms of > this Lesser General Public License (also called "this License"). > Each licensee is addressed as "you". > > A "library" means a collection of software functions and/or data > prepared so as to be conveniently linked with application programs > (which use some of those functions and data) to form executables. > > The "Library", below, refers to any such software library or work > which has been distributed under these terms. A "work based on the > Library" means either the Library or any derivative work under > copyright law: that is to say, a work containing the Library or a > portion of it, either verbatim or with modifications and/or translated > straightforwardly into another language. (Hereinafter, translation is > included without limitation in the term "modification".) > > "Source code" for a work means the preferred form of the work for > making modifications to it. For a library, complete source code means > all the source code for all modules it contains, plus any associated > interface definition files, plus the scripts used to control compilation > and installation of the library. > > Activities other than copying, distribution and modification are not > covered by this License; they are outside its scope. The act of > running a program using the Library is not restricted, and output from > such a program is covered only if its contents constitute a work based > on the Library (independent of the use of the Library in a tool for > writing it). Whether that is true depends on what the Library does > and what the program that uses the Library does. > > 1. You may copy and distribute verbatim copies of the Library's > complete source code as you receive it, in any medium, provided that > you conspicuously and appropriately publish on each copy an > appropriate copyright notice and disclaimer of warranty; keep intact > all the notices that refer to this License and to the absence of any > warranty; and distribute a copy of this License along with the > Library. > > You may charge a fee for the physical act of transferring a copy, > and you may at your option offer warranty protection in exchange for a > fee. > > 2. You may modify your copy or copies of the Library or any portion > of it, thus forming a work based on the Library, and copy and > distribute such modifications or work under the terms of Section 1 > above, provided that you also meet all of these conditions: > > a) The modified work must itself be a software library. > > b) You must cause the files modified to carry prominent notices > stating that you changed the files and the date of any change. > > c) You must cause the whole of the work to be licensed at no > charge to all third parties under the terms of this License. > > d) If a facility in the modified Library refers to a function or a > table of data to be supplied by an application program that uses > the facility, other than as an argument passed when the facility > is invoked, then you must make a good faith effort to ensure that, > in the event an application does not supply such function or > table, the facility still operates, and performs whatever part of > its purpose remains meaningful. > > (For example, a function in a library to compute square roots has > a purpose that is entirely well-defined independent of the > application. Therefore, Subsection 2d requires that any > application-supplied function or table used by this function must > be optional: if the application does not supply it, the square > root function must still compute square roots.) > > These requirements apply to the modified work as a whole. If > identifiable sections of that work are not derived from the Library, > and can be reasonably considered independent and separate works in > themselves, then this License, and its terms, do not apply to those > sections when you distribute them as separate works. But when you > distribute the same sections as part of a whole which is a work based > on the Library, the distribution of the whole must be on the terms of > this License, whose permissions for other licensees extend to the > entire whole, and thus to each and every part regardless of who wrote > it. > > Thus, it is not the intent of this section to claim rights or contest > your rights to work written entirely by you; rather, the intent is to > exercise the right to control the distribution of derivative or > collective works based on the Library. > > In addition, mere aggregation of another work not based on the Library > with the Library (or with a work based on the Library) on a volume of > a storage or distribution medium does not bring the other work under > the scope of this License. > > 3. You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. To do > this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version 2, > instead of to this License. (If a newer version than version 2 of the > ordinary GNU General Public License has appeared, then you can specify > that version instead if you wish.) Do not make any other change in > these notices. > > Once this change is made in a given copy, it is irreversible for > that copy, so the ordinary GNU General Public License applies to all > subsequent copies and derivative works made from that copy. > > This option is useful when you wish to copy part of the code of > the Library into a program that is not a library. > > 4. You may copy and distribute the Library (or a portion or > derivative of it, under Section 2) in object code or executable form > under the terms of Sections 1 and 2 above provided that you accompany > it with the complete corresponding machine-readable source code, which > must be distributed under the terms of Sections 1 and 2 above on a > medium customarily used for software interchange. > > If distribution of object code is made by offering access to copy > from a designated place, then offering equivalent access to copy the > source code from the same place satisfies the requirement to > distribute the source code, even though third parties are not > compelled to copy the source along with the object code. > > 5. A program that contains no derivative of any portion of the > Library, but is designed to work with the Library by being compiled or > linked with it, is called a "work that uses the Library". Such a > work, in isolation, is not a derivative work of the Library, and > therefore falls outside the scope of this License. > > However, linking a "work that uses the Library" with the Library > creates an executable that is a derivative of the Library (because it > contains portions of the Library), rather than a "work that uses the > library". The executable is therefore covered by this License. > Section 6 states terms for distribution of such executables. > > When a "work that uses the Library" uses material from a header file > that is part of the Library, the object code for the work may be a > derivative work of the Library even though the source code is not. > Whether this is true is especially significant if the work can be > linked without the Library, or if the work is itself a library. The > threshold for this to be true is not precisely defined by law. > > If such an object file uses only numerical parameters, data > structure layouts and accessors, and small macros and small inline > functions (ten lines or less in length), then the use of the object > file is unrestricted, regardless of whether it is legally a derivative > work. (Executables containing this object code plus portions of the > Library will still fall under Section 6.) > > Otherwise, if the work is a derivative of the Library, you may > distribute the object code for the work under the terms of Section 6. > Any executables containing that work also fall under Section 6, > whether or not they are linked directly with the Library itself. > > 6. As an exception to the Sections above, you may also combine or > link a "work that uses the Library" with the Library to produce a > work containing portions of the Library, and distribute that work > under terms of your choice, provided that the terms permit > modification of the work for the customer's own use and reverse > engineering for debugging such modifications. > > You must give prominent notice with each copy of the work that the > Library is used in it and that the Library and its use are covered by > this License. You must supply a copy of this License. If the work > during execution displays copyright notices, you must include the > copyright notice for the Library among them, as well as a reference > directing the user to the copy of this License. Also, you must do one > of these things: > > a) Accompany the work with the complete corresponding > machine-readable source code for the Library including whatever > changes were used in the work (which must be distributed under > Sections 1 and 2 above); and, if the work is an executable linked > with the Library, with the complete machine-readable "work that > uses the Library", as object code and/or source code, so that the > user can modify the Library and then relink to produce a modified > executable containing the modified Library. (It is understood > that the user who changes the contents of definitions files in the > Library will not necessarily be able to recompile the application > to use the modified definitions.) > > b) Use a suitable shared library mechanism for linking with the > Library. A suitable mechanism is one that (1) uses at run time a > copy of the library already present on the user's computer system, > rather than copying library functions into the executable, and (2) > will operate properly with a modified version of the library, if > the user installs one, as long as the modified version is > interface-compatible with the version that the work was made with. > > c) Accompany the work with a written offer, valid for at > least three years, to give the same user the materials > specified in Subsection 6a, above, for a charge no more > than the cost of performing this distribution. > > d) If distribution of the work is made by offering access to copy > from a designated place, offer equivalent access to copy the above > specified materials from the same place. > > e) Verify that the user has already received a copy of these > materials or that you have already sent this user a copy. > > For an executable, the required form of the "work that uses the > Library" must include any data and utility programs needed for > reproducing the executable from it. However, as a special exception, > the materials to be distributed need not include anything that is > normally distributed (in either source or binary form) with the major > components (compiler, kernel, and so on) of the operating system on > which the executable runs, unless that component itself accompanies > the executable. > > It may happen that this requirement contradicts the license > restrictions of other proprietary libraries that do not normally > accompany the operating system. Such a contradiction means you cannot > use both them and the Library together in an executable that you > distribute. > > 7. You may place library facilities that are a work based on the > Library side-by-side in a single library together with other library > facilities not covered by this License, and distribute such a combined > library, provided that the separate distribution of the work based on > the Library and of the other library facilities is otherwise > permitted, and provided that you do these two things: > > a) Accompany the combined library with a copy of the same work > based on the Library, uncombined with any other library > facilities. This must be distributed under the terms of the > Sections above. > > b) Give prominent notice with the combined library of the fact > that part of it is a work based on the Library, and explaining > where to find the accompanying uncombined form of the same work. > > 8. You may not copy, modify, sublicense, link with, or distribute > the Library except as expressly provided under this License. Any > attempt otherwise to copy, modify, sublicense, link with, or > distribute the Library is void, and will automatically terminate your > rights under this License. However, parties who have received copies, > or rights, from you under this License will not have their licenses > terminated so long as such parties remain in full compliance. > > 9. You are not required to accept this License, since you have not > signed it. However, nothing else grants you permission to modify or > distribute the Library or its derivative works. These actions are > prohibited by law if you do not accept this License. Therefore, by > modifying or distributing the Library (or any work based on the > Library), you indicate your acceptance of this License to do so, and > all its terms and conditions for copying, distributing or modifying > the Library or works based on it. > > 10. Each time you redistribute the Library (or any work based on the > Library), the recipient automatically receives a license from the > original licensor to copy, distribute, link with or modify the Library > subject to these terms and conditions. You may not impose any further > restrictions on the recipients' exercise of the rights granted herein. > You are not responsible for enforcing compliance by third parties with > this License. > > 11. If, as a consequence of a court judgment or allegation of patent > infringement or for any other reason (not limited to patent issues), > conditions are imposed on you (whether by court order, agreement or > otherwise) that contradict the conditions of this License, they do not > excuse you from the conditions of this License. If you cannot > distribute so as to satisfy simultaneously your obligations under this > License and any other pertinent obligations, then as a consequence you > may not distribute the Library at all. For example, if a patent > license would not permit royalty-free redistribution of the Library by > all those who receive copies directly or indirectly through you, then > the only way you could satisfy both it and this License would be to > refrain entirely from distribution of the Library. > > If any portion of this section is held invalid or unenforceable under any > particular circumstance, the balance of the section is intended to apply, > and the section as a whole is intended to apply in other circumstances. > > It is not the purpose of this section to induce you to infringe any > patents or other property right claims or to contest validity of any > such claims; this section has the sole purpose of protecting the > integrity of the free software distribution system which is > implemented by public license practices. Many people have made > generous contributions to the wide range of software distributed > through that system in reliance on consistent application of that > system; it is up to the author/donor to decide if he or she is willing > to distribute software through any other system and a licensee cannot > impose that choice. > > This section is intended to make thoroughly clear what is believed to > be a consequence of the rest of this License. > > 12. If the distribution and/or use of the Library is restricted in > certain countries either by patents or by copyrighted interfaces, the > original copyright holder who places the Library under this License may add > an explicit geographical distribution limitation excluding those countries, > so that distribution is permitted only in or among countries not thus > excluded. In such case, this License incorporates the limitation as if > written in the body of this License. > > 13. The Free Software Foundation may publish revised and/or new > versions of the Lesser General Public License from time to time. > Such new versions will be similar in spirit to the present version, > but may differ in detail to address new problems or concerns. > > Each version is given a distinguishing version number. If the Library > specifies a version number of this License which applies to it and > "any later version", you have the option of following the terms and > conditions either of that version or of any later version published by > the Free Software Foundation. If the Library does not specify a > license version number, you may choose any version ever published by > the Free Software Foundation. > > 14. If you wish to incorporate parts of the Library into other free > programs whose distribution conditions are incompatible with these, > write to the author to ask for permission. For software which is > copyrighted by the Free Software Foundation, write to the Free > Software Foundation; we sometimes make exceptions for this. Our > decision will be guided by the two goals of preserving the free status > of all derivatives of our free software and of promoting the sharing > and reuse of software generally. > > NO WARRANTY > > 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO > WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. > EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR > OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY > KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE > IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE > LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME > THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. > > 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN > WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY > AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU > FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR > CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE > LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING > RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A > FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF > SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH > DAMAGES. > > END OF TERMS AND CONDITIONS > > How to Apply These Terms to Your New Libraries > > If you develop a new library, and you want it to be of the greatest > possible use to the public, we recommend making it free software that > everyone can redistribute and change. You can do so by permitting > redistribution under these terms (or, alternatively, under the terms of the > ordinary General Public License). > > To apply these terms, attach the following notices to the library. It is > safest to attach them to the start of each source file to most effectively > convey the exclusion of warranty; and each file should have at least the > "copyright" line and a pointer to where the full notice is found. > > > Copyright (C) > > This library is free software; you can redistribute it and/or > modify it under the terms of the GNU Lesser General Public > License as published by the Free Software Foundation; either > version 2.1 of the License, or (at your option) any later version. > > This library is distributed in the hope that it will be useful, > but WITHOUT ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > Lesser General Public License for more details. > > You should have received a copy of the GNU Lesser General Public > License along with this library; if not, write to the Free Software > Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > > Also add information on how to contact you by electronic and paper mail. > > You should also get your employer (if you work as a programmer) or your > school, if any, to sign a "copyright disclaimer" for the library, if > necessary. Here is a sample; alter the names: > > Yoyodyne, Inc., hereby disclaims all copyright interest in the > library `Frob' (a library for tweaking knobs) written by James Random Hacker. > > , 1 April 1990 > Ty Coon, President of Vice > > That's all there is to it! > ------------------------ end of proposed license ------------------ > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From gjhanna at gmail.com Sun Mar 11 14:21:17 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Mon, 12 Mar 2007 09:21:17 +1300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hi Pavel, We are using RXTX under VMWare server in production, quite satisfactorily. We're using Red Hat Enterprise Server 4, and ... Whatever the "enterprise" VMWare product is. Regards, Greg H > Subject: [Rxtx] RXTX under VMWare server > To: rxtx at qbang.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. [ ... snip ... ] -- Pavel Parkhomenko -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070311/4cebb6f9/attachment-0002.html From gergg at cox.net Sun Mar 11 23:39:19 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 12 Mar 2007 00:39:19 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: <45F4E787.6050502@cox.net> Trent Jarvi wrote: > I can start going through the method interfaces later this week and giving > feedback. I would suggest that the JSR should not be too generic in > nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel > drivers that intend to look like EIA232 ports at the kernel driver level. > > some ideas: > > EIA232PortInterface > TermiosInterface > SerialPortInterface > > Something that differentiates this from thing like USB, I2C, ... which > should not have to deal with legacy serial claiming to be the comm api. I'm going to throw out a suggestion, which I am mostly serious about. What would happen if we took the appropriate bits of the J2ME connector API, and just used that as the new COMM API so that finally JSE and JME had a common foundation for these kinds of things? Gregg Wonderly From ra85551 at gmail.com Mon Mar 12 09:08:37 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Mon, 12 Mar 2007 18:08:37 +0300 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Should any application use the modem, HyperTerminal won't be able to talk to the modem. But it actually can send and receive AT comands, while my application cannot :-( > Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Thansk for the reference. I examined that example and found that there's no significant differences between my read/write implementation and that one, except that SimpleSnuV1 listens for serialEvent's, but not for sake of data retrieval, just for printing them out - I don't know why ;-) > Note that modems could care less what OS is on top. If you are trying to > match new lines to the OS and sending it to the mode for AT commands, > thats probably a mistake. I do send strings to serial port, not to OS, and do try to get answers back. If it is the mistake, what's the right way? > Also it would not hurt to print out the > individual bytes that you are sending to make sure they did not get > mangled along the path. Yeah, I am printing these bytes before doing write, but it means that I only see what I intend to write. How can I ensure that these bytes have gone out of the box and reached my modem? BTW, I found that my send/receive method is complex enough, so I've rewritten it. Please, see the following code and point any mistakes, because I don't know where can they remain yet. private static final int LARGE_TIMEOUT = 15000; private static final int SMALL_TIMEOUT = 500; ... private String sendATCommand(String command, String waitFor, boolean isRegex, boolean isAddCRLF) throws BeaconConnectException { byte[] buffer = new byte[512]; int offset; String result = ""; try { if (waitFor != null) { serialPort.enableReceiveTimeout(LARGE_TIMEOUT); } else { serialPort.enableReceiveTimeout(SMALL_TIMEOUT); } if (command != null) { OutputStream serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } offset = 0; InputStream serialInput = serialPort.getInputStream(); while (serialInput.available() != -1) { int bytesRead = serialInput.read(buffer, offset, buffer.length - offset); if (bytesRead == 0) { break; } offset += bytesRead; result = new String(buffer, 0, offset).trim(); if (waitFor != null) { System.out.println(result); if (isRegex && result.matches(waitFor) || result.contains(waitFor)) { break; } } } } catch (UnsupportedCommOperationException e) { throw new MyException("unsupported operation"); } catch (IOException e) { throw new MytException("serial I/O error"); } return result; } -- Pavel Parkhomenko From clayno at hotpop.com Thu Mar 15 02:47:34 2007 From: clayno at hotpop.com (Christopher Layno) Date: Thu, 15 Mar 2007 16:47:34 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi, we're using the latest release of rxtx (2.1-7r2) for our system that has two applications using the library. one application sends requests to the modem while the other simply checks the modem status. we deployed our system on a pentium machine with red hat linux 9.0 installed. now the problem arises when these two applications try to access the same modem at the same time. one of them will eventually have to throw the PortInUseException as shown below: 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException gnu.io.PortInUseException: root PID = 743 Program = java root PID = 743 Program = java root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) this was expected. what we didn't expect though was that if we repeat the scenario 5 times, always 5 times, the application would also throw a VM error: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4473CD21 Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so Current Java thread: at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) - locked <0x44cfd4c8> (a gnu.io.CommPortIdentifier) at ************ at ************ - locked <0x4476a468> (a **********) at ************ at ************ at ************ at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java :261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages( TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run( TCPTransport.java:701) at java.lang.Thread.run(Thread.java:534) note: i replaced some sensitive data with asterisks our team has looked everywhere on the internet, including your mail archives, for a solution to this problem but to no avail. i really hope you could help us out on this one. thanks in advance! best regards, chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070315/1936460a/attachment-0002.html From tjarvi at qbang.org Fri Mar 16 04:30:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 04:30:25 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: On Thu, 15 Mar 2007, Christopher Layno wrote: > hi, > > we're using the latest release of rxtx (2.1-7r2) for our system that has two > applications using the library. one application sends requests to the modem > while the other simply checks the modem status. we deployed our system on a > pentium machine with red hat linux 9.0 installed. > > now the problem arises when these two applications try to access the same > modem at the same time. one of them will eventually have to throw the > PortInUseException as shown below: > > 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException > gnu.io.PortInUseException: root PID = 743 Program = java root PID = > 743 Program = java root PID = 743 Program = ??? root PID = 743 Program > = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root > PID = 743 Program = ??? root PID = 743 Program = ??? > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > > this was expected. what we didn't expect though was that if we repeat the > scenario 5 times, always 5 times, the application would also throw a VM > error: > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x4473CD21 > Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 > Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so > > Current Java thread: > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) Hi Chris The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. The code is originally by Werner Almesberger. He gave us permission to use it in rxtx. You might look at what has changed since 1998 in his fuser application. Or you can just do like other OSs and do the following in fuserImp.c JNIEXPORT jstring JNICALL Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv *env, jobject obj, jstring arg) { return (*env)->NewStringUTF(env, "Unknown Application"); } It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. -- Trent Jarvi tjarvi at qang.org From Adrien.TOS at ingenico.com Fri Mar 16 05:11:12 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Fri, 16 Mar 2007 12:11:12 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903CBC312@frsnprexc1.usr.ingenico.loc> Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070316/972ab214/attachment-0002.html From joachim at buechse.de Fri Mar 16 05:13:24 2007 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 16 Mar 2007 12:13:24 +0100 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. From tjarvi at qbang.org Fri Mar 16 16:36:29 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 16:36:29 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Fri Mar 16 16:02:23 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 16 Mar 2007 18:02:23 -0400 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Not all platforms are Unix based. Also mixing native library usage and command-line calls is not an elegant solution, IMHO. One or the other, but not both. Andre On 16-Mar-07, at 07:13 , Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is > trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We >> only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From clayno at hotpop.com Sun Mar 18 22:17:28 2007 From: clayno at hotpop.com (Christopher Layno) Date: Mon, 19 Mar 2007 12:17:28 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi everyone, thank you so much for your replies. they were really helpful. anyway, before i sent the email, my team was already implementing a temporary solution by using joachim's suggestion. we invoked a lsof command from our java code although i share the same concern with trent and andre-john about portability issues. that's why i said it's just temporary. my superiors have yet to approve our bug fix. so my question now is this: is recompiling the rxtx source code the only way to solve this problem? because if it's the only solution, then i think my superiors would rather have a new release from the rxtx community itself that fixes this bug(?) rather than have my team recompile the source code. best regards, chris Trent Jarvi wrote: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. ... It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070318/237463b2/attachment-0002.html From tjarvi at qbang.org Mon Mar 19 16:20:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Mar 2007 16:20:52 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: Hi Chris I can compile a new version after the 21st if you do not feel comfortable doing so. Please send me an email reminder off-line then. On Mon, 19 Mar 2007, Christopher Layno wrote: > hi everyone, > > thank you so much for your replies. they were really helpful. > > anyway, before i sent the email, my team was already implementing a > temporary solution by using joachim's suggestion. > we invoked a lsof command from our java code although i share the same > concern with trent and andre-john about > portability issues. that's why i said it's just temporary. my superiors have > yet to approve our bug fix. > > so my question now is this: is recompiling the rxtx source code the only way > to solve this problem? because if it's the only > solution, then i think my superiors would rather have a new release from the > rxtx community itself that fixes this bug(?) > rather than have my team recompile the source code. > > best regards, > > chris > > Trent Jarvi wrote: > > Hi Joachim > > It would be nice to have that functionality but calling the program > introduces too many issues imho. Explaining to someone why rxtx invoked a > rogue lsof does not sound very interesting. > > On Fri, 16 Mar 2007, Joachim Buechse wrote: > > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: > > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. > > _______________________________________________ > Rxtx mailing list > Rxtx 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 Eric.Arseneau at sun.com Tue Mar 20 11:47:33 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Tue, 20 Mar 2007 10:47:33 -0700 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 Message-ID: <46001E35.9040608@sun.com> Anyone have any experience with RXTX working with JDK 6 on other platforms ? From mm at UDel.Edu Tue Mar 20 12:18:29 2007 From: mm at UDel.Edu (Mike Markowski) Date: Tue, 20 Mar 2007 14:18:29 -0400 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 In-Reply-To: <46001E35.9040608@sun.com> References: <46001E35.9040608@sun.com> Message-ID: <46002575.4000306@udel.edu> Eric Arseneau wrote: > Anyone have any experience with RXTX working with JDK 6 on other platforms ? I'm using 32 bit intel, gentoo linux, jdk6 with no problems. My applications only use a serial port, though, nothing on the parallel port. Mike From falko.guderian at gmx.de Wed Mar 21 08:17:35 2007 From: falko.guderian at gmx.de (Falko Guderian) Date: Wed, 21 Mar 2007 15:17:35 +0100 Subject: [Rxtx] RXTX binaries for SH4 Message-ID: <46013E7F.40102@gmx.de> Dear developers, I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no possiblities to compile the source code. Better, I'm not able to do this at the moment. Can you provide me with rxtxSerial.dll (SH4) in the rxtx-2.1-8-testing version? (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) The reason for the testing version is I need custom baud rates. Thanks for help. Kind regards, Falko Guderian From tjarvi at qbang.org Wed Mar 21 21:38:37 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Mar 2007 21:38:37 -0600 (MDT) Subject: [Rxtx] RXTX binaries for SH4 In-Reply-To: <46013E7F.40102@gmx.de> References: <46013E7F.40102@gmx.de> Message-ID: On Wed, 21 Mar 2007, Falko Guderian wrote: > Dear developers, > > I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no > possiblities to compile the source code. Better, I'm not able to do this > at the moment. Can you provide me with rxtxSerial.dll (SH4) in the > rxtx-2.1-8-testing version? > (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) > > The reason for the testing version is I need custom baud rates. > > Thanks for help. > Hi Falko WinCE binary format is not supported by gcc. That makes compiling limited to those familiar with the WinCE tools. I hope someone is able to provide them for you but it is not likely. WinCE has been compiled by others in the past but rxtx.org builds have never included WinCE. There is some information with the source concerning WinCE builds if you decide to do it. We can share your results too if you like. The source in the WinCE has never been updated for the custom baud rate. That would need changes from the main source I presume. If you look at the source, you will note that Michal Hobot created a mini fork in the source to handle wince but it has not been updated for 3 years. -- Trent Jarvi tjarvi at qbang.org From Adrien.TOS at ingenico.com Thu Mar 22 07:08:55 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Thu, 22 Mar 2007 14:08:55 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Hi everybody, Do you have any comments on this issue? Thanks! AT ________________________________ De : Adrien TOS Envoy? : vendredi 16 mars 2007 12:11 ? : 'rxtx at qbang.org' Cc : Adrien TOS Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070322/2306c538/attachment-0002.html From jeremy.reeve at zen.co.uk Mon Mar 19 07:36:04 2007 From: jeremy.reeve at zen.co.uk (Jeremy S. Reeve) Date: Mon, 19 Mar 2007 13:36:04 +0000 Subject: [Rxtx] rxtx failing to compile on Fedora Core 6 Message-ID: <1174311364.21865.6.camel@d9thc> When trying to compile latest source : rxtx-2.1-7r2 I get the following when running configure: ---------------- checking os.version 2.6.18-1.2200.fc5smp WARNING: configure is having a hard time determining which directory contains the file jni_md.h. Edit Makefile and fix the variable JAVANATINC to point to the correct directory. The following options are available: /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/ /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/linux/ If there are more than one option available the first was selected. WARNING: Kernel include files do not match the current kernel configure: creating ./config.status ------------------------ which seems OK checking the resultant Makefile but when attempting to build with gmake install I get the following output : ---------------------- 34 problems (34 warnings)/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/javah -classpath .:/home/jsr/rxtxsrc/rxtx-2.1-7r2:/home/jsr/rxtxsrc/rxtx-2.1-7r2/src:/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/ext/RXTXcomm.jar -d i686-pc-linux-gnu -jni `(for i in CommDriver CommPortEnumerator CommPortIdentifier CommPort CommPortOwnershipListener Configure I2C I2CPortEvent I2CPortEventListener I2CPort LPRPort NoSuchPortException ParallelPortEvent ParallelPortEventListener ParallelPort PortInUseException Raw RawPortEvent RawPortEventListener RawPort RS485 RS485PortEvent RS485PortEventListener RS485Port RXTXCommDriver RXTXPort RXTXVersion SerialPortEvent SerialPortEventListener SerialPort UnsupportedCommOperationException UnSupportedLoggerException Zystem;do \ if grep > /dev/null native.* \( /home/jsr/rxtxsrc/rxtx-2.1-7r2/./src/$i.java; then \ echo gnu.io.$i; \ fi; \ done)` i686-pc-linux-gnu/gnu_io_CommPortIdentifier.h: No such file or directory make: *** [/home/jsr/rxtxsrc/rxtx-2.1-7r2/gnu/io/CommDriver.class] Error 1 ------------------------ Any ideas or pointers? Regards, Jeremy From tjarvi at qbang.org Sat Mar 24 08:12:54 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 Mar 2007 08:12:54 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > From Adrien.TOS at ingenico.com Sat Mar 24 11:53:22 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Sat, 24 Mar 2007 18:53:22 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> I do not have the threshold setting enabled, I have explicitely disabled it with: port_.disableReceiveThreshold(); I have also run the same tests with the threshold setting enabled, but they also fail in the same way as described below. So it seems there is a problem with timeout handling on Win32? ________________________________ From: rxtx-bounces at qbang.org on behalf of Trent Jarvi Sent: Sat 3/24/2007 3:12 PM To: RXTX Developers and Users Subject: Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 8312 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20070324/f9e39c9b/attachment-0002.bin From greg.johnson at manchester.ac.uk Sun Mar 25 13:41:36 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Sun, 25 Mar 2007 21:41:36 +0200 Subject: [Rxtx] Mac intel weirdness Message-ID: Hi folks, I'm trying to get rxtx to work on my macbook pro with a USB-serial dongle on it. I am using the 2.1-8 code from the CVS (though it seems to report itself as 2.1-7: makes it difficult to prove to oneself that the changes have 'taken'! - line 4210 in SerialImp.c, line 40 in RXTXVersion.java) I am trying the 2.1-8 because of horrible lock problems in 2.1-7. However, the serialport closure code seems to be broken - it won't close because it believes the (previously opened!) port doesn't exist. Here is what I'm trying: 0. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "false" 1. Open a port Serialport serialport = (SerialPort) commportidentifier.open ("test",100); 2. Talk to a device ... 3. Close port serialport.close(); 4. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "true" - why is this? 5. Try to reopen port Serialport serialport2 = (SerialPort) commportidentifier.open("test", 100); throws PortInUseException. I've dug around a bit in the source, and it seems the SerialPort.close () should call the CommPortIdentifier.internalClosePort() (line 67 of CommPort.java). However, I crash out with the NoSuchPortException when getPortIdentifier is called. Which seems quite weird to me, seeing as it is called on this - which was create just beforehand. Does anyone know how to fix this? Cheers, greg From knute at frazmtn.com Sat Mar 24 10:32:38 2007 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 24 Mar 2007 09:32:38 -0700 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc>, Message-ID: <4604F036.17833.135298@knute.frazmtn.com> > >The behavior of timeout depends upon the setting of the threshold. Do you >have the threshold setting? > This is the same bug I reported last fall. There was a fellow that sent me an email asking if it had been fixed. I told him I didn't think so. He got somebody to write a fix for him but I have not been able to contact him again for the actual changes. The inaccurate timeout and the failure of blocking when no timeouts are set is a serious bug in my humble opinion and renders the software unusable for my applications. I'd really like to have an alternative to the Sun comm api but there just isn't one that I know of. -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Mar 26 16:17:00 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 26 Mar 2007 16:17:00 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> Message-ID: >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. From ra85551 at gmail.com Tue Mar 27 10:18:36 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Tue, 27 Mar 2007 20:18:36 +0400 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Ultimately I found a solution. At first, that wasn't actually the VMWare + WinXP + RXTX issue, that was WinXP + RXTX issue. But on pure XP it sometimes workes, sometimes not, while under VMWare I had never seen my snippet working at all. SimpleSnuV1.java would not help me, because there is only one line I missed, and SimpleSnuV1.java also doesn't contain it! It is as follows: serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_OUT | SerialPort.FLOWCONTROL_RTSCTS_IN); Thank you for your attention. -- Pavel Parkhomenko From griff at op.pl Wed Mar 28 01:28:19 2007 From: griff at op.pl (griff@op.pl) Date: Wed, 28 Mar 2007 09:28:19 +0200 Subject: [Rxtx] No blocking read on Windows. Message-ID: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/5d07d571/attachment-0002.html -------------- next part -------------- Hi, I have problem that InputStram.read() (SerialPort)?returns -1 instead blocking and waiting for data. I found that this problem was ?known in 2005 : ? >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > >> Hi Trent >> >> Thanks for the fast response. >> Here's a Q&D test program for the blocking read on windows that just >> attempts to read one byte, and prints the resulting byte. On my system it >> returns -1, where I expect that it keeps waiting for data. >> >This isn't happening on Linux so the bug is in src/termios.c.? I'll have >something this weekend to fix that. I'm using RXTX 2.1.7r2 and the problem still is here. Im using Windows XP and java 1.5 disableReciveTimeout() and disableReciveTreshhold() dont help. ? best regards ? Piotr Zielniok From Adrien.TOS at ingenico.com Wed Mar 28 01:40:46 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Wed, 28 Mar 2007 09:40:46 +0200 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903E88880@frsnprexc1.usr.ingenico.loc> Looking at the code, it seems there is no support for infinite timeout? And maybe the count++ < 20 condition is breaking out of the loop too early? The only condition to break out of the loop should either be the timeout has expired or the number of requested bytes has been received. -----Message d'origine----- De : rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] De la part de Trent Jarvi Envoy? : mardi 27 mars 2007 00:17 ? : RXTX Developers and Users Objet : Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From j.kenneth.gentle at acm.org Wed Mar 28 06:44:15 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 28 Mar 2007 08:44:15 -0400 Subject: [Rxtx] No blocking read on Windows. In-Reply-To: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> References: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> Message-ID: <200703281844.l2SIiITW028614@qbang.org> Just another "ME TOO!" - I'm seeing this problem on Windows XP, jre for windows XP/Embedded. I cranked receiveTimeout up to Integer.MAX_INT, but it doesn't seem to wait that long At 03:28 2007-03-28, you wrote: >Hi, >I have problem that InputStram.read() (SerialPort) returns -1 >instead blocking and waiting for data. I found that this problem >was known in 2005 : > > >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > > > >> Hi Trent > >> > >> Thanks for the fast response. > >> Here's a Q&D test program for the blocking read on windows that just > >> attempts to read one byte, and prints the resulting byte. On my system it > >> returns -1, where I expect that it keeps waiting for data. > >> > > >This isn't happening on Linux so the bug is in src/termios.c. I'll have > >something this weekend to fix that. > >I'm using RXTX 2.1.7r2 and the problem still is here. >Im using Windows XP and java 1.5 >disableReciveTimeout() and disableReciveTreshhold() dont help. > >best regards > >Piotr Zielniok > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From greg.johnson at manchester.ac.uk Wed Mar 28 14:43:29 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Wed, 28 Mar 2007 22:43:29 +0200 Subject: [Rxtx] Cannot close and reopen serial port Message-ID: <377F9765-7A9D-4CE9-9176-FFB63A2594F0@manchester.ac.uk> Dear all, It appears I cannot close a port properly: SerialPort serialport = portid.open("myprog",100); // do some stuff, all works fine serialport.close(); // all seems fine but... SerialPort sp2 = portid.open("myprog",100); throws PortInUseException. And when I dig into the rxtx code, I find in CommPort.java, in close(): CommPortIdentifier cp = CommPortIdentifier.getPortIdentifier(this); (line 64 or there abouts) but this throws a NoSuchPortException which is caught but ignored (line 74ish). Can anyone suggest how this could happen: a port that was valid, opened, and used, throws a NSPE when it comes to closing it? I'm pulling my (remaining) hair out over this one! Cheers, greg PS And thanks for RXTX - it's great to have! PPS (21.-7. winxp/osx both, java 1.5) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/c28852fc/attachment-0002.html From rxtx at vrijheidslaan.net Fri Mar 30 16:52:50 2007 From: rxtx at vrijheidslaan.net (Rob) Date: Fri, 30 Mar 2007 22:52:50 -0000 Subject: [Rxtx] Cvs Question Message-ID: <61896.80.126.150.87.1175295162.squirrel@webmail.provalue.nl> Hi There, Im trying to get the latest version to work on mac osx. Problem is that i can't checkout version 2.1.8. Probably my fault but can some one please give me the alternative commands for: [user at myhost]$ export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot [user at myhost]$ cvs login Thanx, Rob From ra85551 at gmail.com Thu Mar 1 03:47:06 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Thu, 1 Mar 2007 13:47:06 +0300 Subject: [Rxtx] enableReceiveTimeout() issue Message-ID: Hello, world! I found a limitation of 16300 ms for CommPort's enableReceiveTimeout() method, while in original javax.comm docs there are no any references to that. Is that a bug or feature? I actually need longer timeouts sometimees. -- Pavel Parkhomenko From lyon at docjava.com Thu Mar 1 07:54:17 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 01 Mar 2007 09:54:17 -0500 Subject: [Rxtx] parametric singleton design pattern In-Reply-To: References: <22d55aea0702081207q5e7f6785l352d498d6f5f9fb1@mail.gmail.com> <22d55aea0702100034o3bcf42f3j1d1a6257029a67b0@mail.gmail.com> Message-ID: Hi All, I have been thinking about the use of a design pattern to cache resources that are consumed by processes. Toward that end, I have arrived at a parametric singleton design pattern, which I mentioned on this list some time ago. The idea has been published at: http://www.jot.fm/issues/issue_2007_03/column2 I can't help but think that there should be an API available for dealing with the tracking of serial port usage. Perhaps it is a kind of resource manager called the: SerialPortManager basic prototypes already exist in this vain. See, for example: http://www.ce.rit.edu/research/projects/2005_fall/rt_poolsystem/doc/PoolMon/SerialPortManager.html http://www.eventhelix.com/RealtimeMantra/PatternCatalog/serial_port_design_pattern.htm And others shown by a google search on "SerialPortManager" Cheers! - Doug From Eric.Arseneau at sun.com Thu Mar 1 10:15:03 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:15:03 -0800 Subject: [Rxtx] Any known Java 6 issues with RXTX 2.1-7r2 ? Message-ID: <45E70A17.1060206@sun.com> I just did a test on a recent build of Solaris 11 x86 and it seems that I can connect to my serial device fine when Java 5 is the default, but when Java 6 is the default, no go. Any information ? From Eric.Arseneau at sun.com Thu Mar 1 10:19:58 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:19:58 -0800 Subject: [Rxtx] Mac OS X and missing data Message-ID: <45E70B3E.7040908@sun.com> We have a device which is USB based but presents itself as a serial port to a machine. On my MacBook Pro I can get excellent throughput if I get my device to send data as quickly as possible. On the desktop side, if I do an type of disk IO to log the data I get, I end up with some missing data at some point. I hooked up a USB analyzer and did confirm that all the data is sent as expected to the desktop from the device. I found a work around for this, buffer the data in memory and only write the data out when I've received it all. However, when the same code and same device is attempted on a co-workers MacBook Pro (same hardware specs), I get errors and must slow down dramatically the device side's sending of data. Any ideas/recommendations on what I can do to get rid of this error ? From what I can tell, it seems that RXTX is not able to wake up to the interrupts coming in indicating data is ready, quickly enough, is there anything I can do ? From chinkaiw at hotmail.com Fri Mar 2 00:57:43 2007 From: chinkaiw at hotmail.com (Wang Chinkai) Date: Fri, 02 Mar 2007 07:57:43 +0000 Subject: [Rxtx] dynamic detect rs232 port Message-ID: Hi all I have a question about detecting rs232 port dynamicly. I have to aceess some port and detect rs232 port at the same time. Some usb device simulates rs232 port , and I can not know what the port name it gets until it connects,so I have to detect it dynamic,but I have to access another rs232 device at the same time. I found a problem. If I use CommPortIdentifier.getPortIdentifiers() to get new port list , and the other rs232 access function will not close port correctly. So , How can I solve it . Thanks. _________________________________________________________________ ?? 2GB ???? Windows Live Mail ????????????? http://ideas.live.com/programpage.aspx?versionid=5d21c51a-b161-4314-9b0e-4911fb2b2e6d From eu259473 at tele2.it Fri Mar 2 06:16:40 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 02 Mar 2007 14:16:40 +0100 Subject: [Rxtx] rxtx on HP tru 64 unix Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070302/706c7a70/attachment-0003.html From tjarvi at qbang.org Fri Mar 2 08:39:33 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 08:39:33 -0700 (MST) Subject: [Rxtx] rxtx on HP tru 64 unix In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, "Giuseppe Marchese" wrote: > Hi > > I try to install rxtx on hp tru 64 but make fails, > There are somebody that do the same and work. > > > Sorry for may english! > > Hi Giuseppe Could you provide a log of the failure? script ./configure make # use gnu make exit The information will be in the typescript created. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 2 19:56:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 19:56:52 -0700 (MST) Subject: [Rxtx] dynamic detect rs232 port In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, Wang Chinkai wrote: > Hi all > > I have a question about detecting rs232 port dynamicly. > > I have to aceess some port and detect rs232 port at the same time. > Some usb device simulates rs232 port , and I can not know > what the port name it gets until it connects,so I have to detect it > dynamic,but I have to access > another rs232 device at the same time. > > I found a problem. Hi Wang This is a known problem. The code is braindead there. In fact there needs to be events even in a rudamentary way when you add a usb dongle. I'm burried in tasks not far from rxtx but not in rxtx. I can't get to the problem but we would accept patches if you dig into it. [I'm getting to the license question earlier too; I don't have another 10%] -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Fri Mar 2 23:19:01 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 01:19:01 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Hi, Under ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable USB -> serial converter(using virtual com port drivers), with using example code pretty much straight out of http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port opens fine, enumerations all work, etc. My application calls for a large amount of data to be transferred in a short amount of time at 2,000,000 baud. My hardware sends approximately 15,232 bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL converter work fine, and the application works using C++. In C++, I do a hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); to open the port, and a boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); to read the port. The variable buffer fills with the 15238 bytes, and returns. If I do a resultz = is.read(cbuf,0,15238); in java with RXTX where is = new BufferedReader(new InputStreamReader(port.getInputStream())); and where resultz is an int, and cbuf is a char [] cbuf, resultz gets EXACTLY 3968 bytes the first time called. If I call it multiple times, I get roughly 11k total(less than what is sent), never more than the 3968 bytes per is.read() call. My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 bytes. I've played with inputbuffersize, receive threshold, receivetimeout, and so on. The FTDI virtual com port drivers that I'm using are rock solid, and have had zero problems with them using a variety of applications, some of my own, some professionally written, etc. No flow control is used anyplace, no RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. No exceptions are being thrown. What am I doing wrong, and what I can adjust to receive the full 15k bytes in one single read? Thanks! Keith From Eric.Arseneau at sun.com Fri Mar 2 23:32:07 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Fri, 02 Mar 2007 22:32:07 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <45E91667.20501@sun.com> This is the same type of thing that is happening to me on Mac OS X and does not seem to behave the same on different machines. I posted a day or two ago on this with subject "Mac OS X and missing data". Would love to hear if there is a solution to this :) From tjarvi at qbang.org Sat Mar 3 10:54:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 10:54:17 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > Hi, > > Under > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable > USB -> serial converter(using virtual com port drivers), with using example > code pretty much straight out of > http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port > opens fine, enumerations all work, etc. > > My application calls for a large amount of data to be transferred in a short > amount of time at 2,000,000 baud. My hardware sends approximately 15,232 > bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL > converter work fine, and the application works using C++. > > In C++, I do a > > hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, > OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); > > to open the port, and a > > boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); > > to read the port. > > The variable buffer fills with the 15238 bytes, and returns. > > If I do a > > resultz = is.read(cbuf,0,15238); in java with RXTX > > where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > > and where resultz is an int, and cbuf is a char [] cbuf, resultz gets > EXACTLY 3968 bytes the first time called. If I call it multiple times, I get > roughly 11k total(less than what is sent), never more than the 3968 bytes > per is.read() call. > > My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 > bytes. > > I've played with inputbuffersize, receive threshold, receivetimeout, and so > on. The FTDI virtual com port drivers that I'm using are rock solid, and > have had zero problems with them using a variety of applications, some of my > own, some professionally written, etc. No flow control is used anyplace, no > RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. > > No exceptions are being thrown. > > What am I doing wrong, and what I can adjust to receive the full 15k bytes > in one single read? > > Thanks! > Hi Keith I would expect a 20 meg application is going to have different behavior with the OS than a smaller application with respect to the kernel memory managment, schedualing, ... Something subtle could be causing problems. With respect to the recieve timeout and threshold, if you set the timeout to zero and the threshold to the size of data you expect, read should not return until it get that data. You may try with a stand alone application that tests just that with the C/C++ API. If the read is returning with less data when tested for short reads, you have found a bug in the device driver more than likely. The USB dongle vendor would probably be interested in knowing about this. As mentioned, these devices are getting very good; almost bug free. I suspect you found a bug though if you did use the threshold and timeout properly. The missing data is typical when not using flow control. When the OS buffering fills, the hardware will start dropping bytes. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:38:52 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:38:52 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> update: I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now instead of 3968. This makes sense. 128 bytes of overhead + 3968 bytes of data = 4096 transfer size 32 bytes of overhead + 992 bytes of data = 1024 transfer size. 1/4 the data = 1/4 the overhead. I rearranged my reading like so: resultz = is.read(cbuf,0,3968); resultz = is.read(cbuf,3968,3968); resultz = is.read(cbuf,7936,3968); while (!(is.ready())); // wait for ready resultz = is.read(cbuf,11904,3334); and this grabs 15,238 bytes total. BUT, I still have the quandry of the screwed up multi-bytes. I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. Approx 8% of the data. The bad bytes always seem to take the flavor of 0x2018, 0x2019, x2022, x2030, x201d. Are these maybe errors and I don't know what they enumerate to? I still can't believe some other layer isn't handling putting those bytes together all in one stream for me. Thanks Keith ----- Original Message ----- From: "Keith" To: "Bob Jacobsen" ; "RXTX Developers and Users" Sent: Saturday, March 03, 2007 11:26 AM Subject: Re: [Rxtx] is.read() only returning 3968 bytes > Bob, > > > Interesting numerical coincidence is that (max USB transfer) - (what > > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > > needed to transfer that much data. > > I was thinking along the same lines. I don't know USB well, but I do know > that those numbers were close enough to warrant investigating the > relationship between them. > > > I think what you're seeing is the internal buffering of the USB data > > stream. You'll need some form of higher-level buffering to smooth > > that out. > > Shouldn't the InputStreamReader() and BufferedReader() provide this type of > buffering? Isn't that the idea behind those? > > > All hypotheses need to be tested. In this case, a test would be to > > check for missing data. If this idea is right, you'll get _all_ the > > data, but you won't be missing characters. > > I did start looking at the data. -- I'm getting weird results. > > I tried this: > > loopzz = 0; > > for (looptwo = 0; looptwo < 100000; looptwo++) { > while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > > }} > > So I'm reading one character at a time. The good news is that loopzz is > exactly 15238 at the end of the routine, which is perfectly correct. I > picked looptwo value out of thin air. > > The weird results come in terms of the values, the data isn't correct at > least in one case. Look here: > > 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > > This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). > But the 0x89 was replaced by 0x2030. Why the heck would the returned value > be 0x2030?? Why is the returned byte completely out of range? Why the > multibyte return? > > From InputStream in the API: > > read > public abstract int read() > throws IOExceptionReads the next byte of data from the > input stream. The value byte is returned as an int in the range 0 to 255. If > no byte is available because the end of the stream has been reached, the > value -1 is returned. This method blocks until input data is available, the > end of the stream is detected, or an exception is thrown. > Value should be 0-255. > > > In my application time is really critical, reading 1 byte at a time is > probably not going to work. > > Thanks Eric & Bob for looking at this. > > Keith > From tjarvi at qbang.org Sat Mar 3 12:52:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 12:52:27 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > update: > > I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now > instead of 3968. > > This makes sense. > > 128 bytes of overhead + 3968 bytes of data = 4096 transfer size > 32 bytes of overhead + 992 bytes of data = 1024 transfer size. > > 1/4 the data = 1/4 the overhead. > > I rearranged my reading like so: > > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. > Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? > > I still can't believe some other layer isn't handling putting those bytes > together all in one stream for me. > The layer for this in Serial land is flow control. Software and hardware flow control prevent the overruns you observe. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:54:41 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:54:41 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <001a01c75dcd$c8802a70$6600a8c0@jbh757ktruws7g> Trent, Thanks for taking the time to reply. > I would expect a 20 meg application is going to have different behavior > with the OS than a smaller application with respect to the kernel memory > managment, schedualing, ... Something subtle could be causing problems. Well, at least I know the VCP drivers, the OS, etc can handle 2mbps reliably. Without hiccuping or dropping bytes. The C++ code works reliably without flow control. > The missing data is typical when not using flow control. When the OS > buffering fills, the hardware will start dropping bytes. I'm actually not getting MISSING data, I'm getting CORRUPTED data. If you look at my most recent post, I'm getting these bad bytes in place of the correct values: 0x2018, 0x2019, x2022, x2030, x201d. Why would is.read() return values not in the range of 0-255 ? Thanks. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 08:59:14 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 07:59:14 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: At 1:19 AM -0500 3/3/07, Keith wrote: >If I do a > >resultz = is.read(cbuf,0,15238); in java with RXTX > >where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > >and where resultz is an int, and cbuf is a char [] cbuf, resultz gets >EXACTLY 3968 bytes the first time called. If I call it multiple times, I get >roughly 11k total(less than what is sent), never more than the 3968 bytes >per is.read() call. > >My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 >bytes. Interesting numerical coincidence is that (max USB transfer) - (what you get) = 4096-3968 = 128 bytes is (almost) the size of the headers needed to transfer that much data. I think what you're seeing is the internal buffering of the USB data stream. You'll need some form of higher-level buffering to smooth that out. All hypotheses need to be tested. In this case, a test would be to check for missing data. If this idea is right, you'll get _all_ the data, but you won't be missing characters. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 09:26:14 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 11:26:14 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Bob, > Interesting numerical coincidence is that (max USB transfer) - (what > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > needed to transfer that much data. I was thinking along the same lines. I don't know USB well, but I do know that those numbers were close enough to warrant investigating the relationship between them. > I think what you're seeing is the internal buffering of the USB data > stream. You'll need some form of higher-level buffering to smooth > that out. Shouldn't the InputStreamReader() and BufferedReader() provide this type of buffering? Isn't that the idea behind those? > All hypotheses need to be tested. In this case, a test would be to > check for missing data. If this idea is right, you'll get _all_ the > data, but you won't be missing characters. I did start looking at the data. -- I'm getting weird results. I tried this: loopzz = 0; for (looptwo = 0; looptwo < 100000; looptwo++) { while (is.ready()) { cbuf[loopzz] = (char) is.read(); loopzz++; }} So I'm reading one character at a time. The good news is that loopzz is exactly 15238 at the end of the routine, which is perfectly correct. I picked looptwo value out of thin air. The weird results come in terms of the values, the data isn't correct at least in one case. Look here: 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). But the 0x89 was replaced by 0x2030. Why the heck would the returned value be 0x2030?? Why is the returned byte completely out of range? Why the multibyte return? >From InputStream in the API: read public abstract int read() throws IOExceptionReads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown. Value should be 0-255. In my application time is really critical, reading 1 byte at a time is probably not going to work. Thanks Eric & Bob for looking at this. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 14:44:50 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 13:44:50 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: Java's "char" type is Unicode. I think what you're seeing is a bug in the byte -> Unicode translation. 0x2018, 0x2019 are the curly open and close quotes. There used to be (and might still be) bugs in the conversion of these in a couple of libc versions. Some of the ASCII -> ISO and ISO -> ASCII routines were a little over-ambitious with respect to handling the open and close quotes, and tried to convert them to the "curly" form inappropriately. Try _not_ casting it to char. Bob At 11:26 AM -0500 3/3/07, Keith wrote: >Bob, > >> Interesting numerical coincidence is that (max USB transfer) - (what >> you get) = 4096-3968 = 128 bytes is (almost) the size of the headers >> needed to transfer that much data. > >I was thinking along the same lines. I don't know USB well, but I do know >that those numbers were close enough to warrant investigating the >relationship between them. > >> I think what you're seeing is the internal buffering of the USB data >> stream. You'll need some form of higher-level buffering to smooth >> that out. > >Shouldn't the InputStreamReader() and BufferedReader() provide this type of >buffering? Isn't that the idea behind those? > >> All hypotheses need to be tested. In this case, a test would be to >> check for missing data. If this idea is right, you'll get _all_ the >> data, but you won't be missing characters. > >I did start looking at the data. -- I'm getting weird results. > >I tried this: > >loopzz = 0; > >for (looptwo = 0; looptwo < 100000; looptwo++) { >while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > >}} > >So I'm reading one character at a time. The good news is that loopzz is >exactly 15238 at the end of the routine, which is perfectly correct. I >picked looptwo value out of thin air. > >The weird results come in terms of the values, the data isn't correct at >least in one case. Look here: > >0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > >This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). >But the 0x89 was replaced by 0x2030. Why the heck would the returned value >be 0x2030?? Why is the returned byte completely out of range? Why the >multibyte return? > >>From InputStream in the API: > >read >public abstract int read() > throws IOExceptionReads the next byte of data from the >input stream. The value byte is returned as an int in the range 0 to 255. If >no byte is available because the end of the stream has been reached, the >value -1 is returned. This method blocks until input data is available, the >end of the stream is detected, or an exception is thrown. >Value should be 0-255. > > >In my application time is really critical, reading 1 byte at a time is >probably not going to work. > >Thanks Eric & Bob for looking at this. > >Keith > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 15:10:11 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 17:10:11 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Bob said ..... > Java's "char" type is Unicode. I think what you're seeing is a bug > in the byte -> Unicode translation. Bob -- I think you hit the nail on the head. I was just coming to the same realization here. I knew that something funny was going on because the same bytes always got "corrupted." I'm pretty sure its in the InputStreamReader() functionality where the conversion junk is happening. Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. I don't know if simply changing the cast is going to work. Since the conversion is happening upstream (pun intended), I don't think my cast is doing this. Also I think the compiler forced me to use the cast. I'm still playing around, and I'll report back once I nail it down. Thanks!! Keith From tjarvi at qbang.org Sat Mar 3 15:59:46 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 15:59:46 -0700 (MST) Subject: [Rxtx] Win64 rxtx Testers? Message-ID: I have compiled win64 binaries of rxtx. Are there any users interested in testing them? If so, I'll look into putting them on the web site. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Mar 3 15:35:06 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 14:35:06 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: Because of this and similar problems, JMRI does all it's serial IO using +only+ byte values. It's a but of a pain, as Java wants to go to char and int types a little too aggressively, but it does solve the "uncontrolled conversions" problems. Bob At 5:10 PM -0500 3/3/07, Keith wrote: >Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > >Bob -- I think you hit the nail on the head. > >I was just coming to the same realization here. I knew that something funny >was going on because the same bytes always got "corrupted." > >I'm pretty sure its in the InputStreamReader() functionality where the >conversion junk is happening. > >Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > >I don't know if simply changing the cast is going to work. Since the >conversion is happening upstream (pun intended), I don't think my cast is >doing this. Also I think the compiler forced me to use the cast. -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mark at mdsh.com Sun Mar 4 11:01:33 2007 From: mark at mdsh.com (Mark Himsley) Date: Sun, 04 Mar 2007 18:01:33 +0000 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: <5C01AC72C200388815C04982@bedroom.mdsh.local> On 03 March 2007 14:38 -0500 Keith wrote: > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT > consistent. Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? It looks like you need to use DataInputStream and DataOutputStream. -- Mark Himsley From tjarvi at qbang.org Sun Mar 4 11:35:08 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 11:35:08 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" > > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > > * Line #21 - Not sure if you need a (TM) mark for > the term "Sun" > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > OK. I'm going through this today. Some groups ask if rxtx could be under their license also. I think this is a good example of why I resist multiple licenses and focus on why the current license may not be usable by them. The RXTX project is a convergence of hobby and commercial interests. I happen to do both right now. The problem with licensing is we have to stay on top of them as they change. Clearly, adding more licenses will not make this easier. I'm acting as the hobby person today. RXTX always favors the hobby people. But as we move forward, I'm going to need to bring this to lawyers at work and explain to them what is going on. Others here may have to do this also. I don't anticipate problems or unexpected changes. The goal is a consistant, comprehendable and usable license as close to what we have now as possible. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 14:52:10 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 14:52:10 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (1/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: I'm breaking this into two parts. I expect the second part will need more attention. Comments first, then the changed material below. On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > Thanks > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. OK. RXTX for consitent use. java should not be capitalized because it does not only mean Sun [TM] Java [TM]. An example of this not meaning Java is when people use RXTX with GCJ. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". There are not any contributors that are in all of RXTX yet but I did update the comment to try to reflect the current situation without making it a nightmare to maintain. I looked to see how the Linux kernel does it as a reference point. > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" The URL can be problematic. I have done so below with a time reference. GNU does not provide version information in their URLS. I picture this being a problem when the version 3 comes out. > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > This will be corrected when the copy is updated to the version linked below. ---------------- begin proposed material involved -------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. ----------------- end proposed material involved -------------------- I'll be looking at the linking issue again next. That should be all that remains other than including the 2.1 version. Let me know if you have problems with anything here. I do not want to dilute the material I post next with these housekeeping tasks. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 16:08:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 16:08:36 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: For those that are wondering what is going on here, this next bit is the meat of the changes. We agreed a long time ago to put this disclaimer in. We did a so so job. It was in rxtx 2.0, not well written, ... So some groups using rxtx that would like to ship rxtx so users don't need to download, install, go to the mail-list to find why it failed, ... Then their legal teams tell them section 5 paragraph 2 is a show stopper. That was never the intent. Now going through what remains... > and might need a (TM) suffix to make Sun happy. Added disclaimer at the ended 'all trademarks belong...' > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. OK. As you can see I was trying to adjust GNU text there for the LGPL. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. used dynamically linked terminology. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". I tried to address this more upfront with an intent statement. Let me know if you have problems with it. I also tried to make it a little more clear what was derived from the GNU solution by moving the link location closer to GNU's suggestion. > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > Thats the intent. Here is the combined fixes. Note that only the material in /*-- --*/ is being touched. The new GPL license is there but unmodified. ------------------------ begin proposed new license ------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. | | An executable that contains no derivative of any portion of RXTX, but | is designed to work with RXTX by being dynamically linked with it, | is considered a "work that uses the Library" subject to the terms and | conditions of the GNU Lesser General Public License. | | The following has been added to the RXTX License to remove | any confusion about linking to RXTX. We want to allow in part what | section 5, paragraph 2 of the LGPL does not permit in the special | case of linking over a controlled interface. The intent is to add a | Java Specification Request or standards body defined interface in the | future as another exception but one is not currently available. | | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface | | As a special exception, the copyright holders of RXTX give you | permission to link RXTX with independent modules that communicate with | RXTX solely through the Sun Microsytems CommAPI interface version 2, | regardless of the license terms of these independent modules, and to copy | and distribute the resulting combined work under terms of your choice, | provided that every copy of the combined work is accompanied by a complete | copy of the source code of RXTX (the version of RXTX used to produce the | combined work), being distributed under the terms of the GNU Lesser General | Public License plus this exception. An independent module is a | module which is not derived from or based on RXTX. | | Note that people who make modified versions of RXTX are not obligated | to grant this special exception for their modified versions; it is | their choice whether to do so. The GNU Lesser General Public License | gives permission to release a modified version without this exception; this | exception also makes it possible to release a modified version which | carries forward this exception. | | You should have received a copy of the GNU Lesser General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA | All trademarks belong to their respective owners. --------------------------------------------------------------------------*/ The original GNU Lesser General Public License Follows. GNU LESSER GENERAL PUBLIC LICENSE Version 2.1, February 1999 Copyright (C) 1991, 1999 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. [This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence the version number 2.1.] Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This license, the Lesser General Public License, applies to some specially designated software packages--typically libraries--of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below. When we speak of free software, we are referring to freedom of use, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish); that you receive source code or can get it if you want it; that you can change the software and use pieces of it in new free programs; and that you are informed that you can do these things. To protect your rights, we need to make restrictions that forbid distributors to deny you these rights or to ask you to surrender these rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library or if you modify it. For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights. We protect your rights with a two-step method: (1) we copyright the library, and (2) we offer you this license, which gives you legal permission to copy, distribute and/or modify the library. To protect each distributor, we want to make it very clear that there is no warranty for the free library. Also, if the library is modified by someone else and passed on, the recipients should know that what they have is not the original version, so that the original author's reputation will not be affected by problems that might be introduced by others. Finally, software patents pose a constant threat to the existence of any free program. We wish to make sure that a company cannot effectively restrict the users of a free program by obtaining a restrictive license from a patent holder. Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license. Most GNU software, including some libraries, is covered by the ordinary GNU General Public License. This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs. When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library. We call this license the "Lesser" General Public License because it does Less to protect the user's freedom than the ordinary General Public License. It also provides other free software developers Less of an advantage over competing non-free programs. These disadvantages are the reason we use the ordinary General Public License for many libraries. However, the Lesser license provides advantages in certain special circumstances. For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License. In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software. For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU operating system, as well as its variant, the GNU/Linux operating system. Although the Lesser General Public License is Less protective of the users' freedom, it does ensure that the user of a program that is linked with the Library has the freedom and the wherewithal to run that program using a modified version of the Library. The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, whereas the latter must be combined with the library in order to run. GNU LESSER GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License Agreement applies to any software library or other program which contains a notice placed by the copyright holder or other authorized party saying it may be distributed under the terms of this Lesser General Public License (also called "this License"). Each licensee is addressed as "you". A "library" means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables. The "Library", below, refers to any such software library or work which has been distributed under these terms. A "work based on the Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term "modification".) "Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library. Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does. 1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) The modified work must itself be a software library. b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change. c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License. d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful. (For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library. In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. 4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange. If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code. 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables. When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law. If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.) Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself. 6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications. You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things: a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.) b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. c) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution. d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place. e) Verify that the user has already received a copy of these materials or that you have already sent this user a copy. For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute. 7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things: a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above. b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work. 8. You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 9. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Library (or any work based on the Library), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Library or works based on it. 10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties with this License. 11. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply, and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 12. If the distribution and/or use of the Library is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Library under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 13. The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation. 14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Libraries If you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the ordinary General Public License). To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Also add information on how to contact you by electronic and paper mail. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the library, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the library `Frob' (a library for tweaking knobs) written by James Random Hacker. , 1 April 1990 Ty Coon, President of Vice That's all there is to it! ------------------------ end of proposed license ------------------ -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sun Mar 4 16:26:04 2007 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 04 Mar 2007 17:26:04 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <45EB558C.3010609@cox.net> Bob Jacobsen wrote: > Because of this and similar problems, JMRI does all it's serial IO > using +only+ byte values. It's a but of a pain, as Java wants to go > to char and int types a little too aggressively, but it does solve > the "uncontrolled conversions" problems. Anytime that you are reading bytes of data that is not printable, unicode text, in Java, you really need to stay away from the Readers. Use input stream only, or you will see unicode valued byte groups converted to unicode "char" values. Gregg Wonderly From joachim at buechse.de Mon Mar 5 04:23:48 2007 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 5 Mar 2007 12:23:48 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> The behaviour is exactly what you asked for in you code. is = new BufferedReader(new InputStreamReader(port.getInputStream())); Readers return Text (ie unicode chars) not bytes. You instantiate the InputStreamReader without saying which charset you want, which means "platform default". As this is on Windows, it will convert Windows characters to equivalent unicode characters. If you want to read bytes, read bytes not Text. Reading bytes is done with InputStream and BufferedInputStream. BTW: The InputStream and Reader methods that read arrays are not guarenteed to fill up the array. You always have to check what you really got, and advance your index accordingly. A typical "read up to 32k" method looks like this: InputStream is= ... // -- determine the max buffer size int len= is.available(); if (len == 0) { len= 32 * 1024; } // -- read all available data byte[] buffer= new byte[len]; int pos= 0; int read; do { read= is.read(buffer, pos, buffer.length - pos); pos= pos + read; } while (read != -1 && pos < buffer.length); Best regards, Joachim --- Joachim B?chse Phone: +41 44 500 2604 Buechse Consulting Hadlaubsteig 2 CH-8006 Z?rich On 03.03.2007, at 23:10, Keith wrote: > Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > > Bob -- I think you hit the nail on the head. > > I was just coming to the same realization here. I knew that > something funny > was going on because the same bytes always got "corrupted." > > I'm pretty sure its in the InputStreamReader() functionality where the > conversion junk is happening. > > Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > > I don't know if simply changing the cast is going to work. Since the > conversion is happening upstream (pun intended), I don't think my > cast is > doing this. Also I think the compiler forced me to use the cast. > > I'm still playing around, and I'll report back once I nail it down. > > Thanks!! > > Keith > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Mon Mar 5 07:25:46 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 05 Mar 2007 08:25:46 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> Message-ID: <45EC286A.8060608@cox.net> Joachim Buechse wrote: > BTW: The InputStream and Reader methods that read arrays are not > guarenteed to fill up the array. You always have to check what you > really got, and advance your index accordingly. A typical "read up to > 32k" method looks like this: > > InputStream is= ... > // -- determine the max buffer size > int len= is.available(); > if (len == 0) { > len= 32 * 1024; > } > // -- read all available data > byte[] buffer= new byte[len]; > int pos= 0; > int read; > do { > read= is.read(buffer, pos, buffer.length - pos); > pos= pos + read; > } while (read != -1 && pos < buffer.length); > My preferred structure is. byte arr[ len ]; int cnt; int off = 0; while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { off += cnt; } This keeps you from adding -1 to pos when the read returns -1. It also skips out when the read is 0 bytes which, is not a described EOF in InputStream java docs, but is a condition I want to be aware of. Gregg Wonderly From joachim at buechse.de Tue Mar 6 02:52:58 2007 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 6 Mar 2007 10:52:58 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <45EC286A.8060608@cox.net> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: The code I copied was from a file resource reader, it shouldn't really be applied to networking/external IO code. Mea culpa. However aborting when you get 0 from read is not always what you want either (you kind of indicated that already). Some unix java implementations will return 0 if the kernel read was aborted with EINTER, which is rarely the point where you want to abort your read - at least not without further checks. A "complete" solution always depends on the events you need to handle and the time the total read could take in reality. In some cases it's worth checking Thread.isInterrupted() in the loop, some code re-loops on 0 but only a limited number of times, some check a total timeout limit, etc... Best regards, Joachim On 05.03.2007, at 15:25, Gregg Wonderly wrote: > My preferred structure is. > > byte arr[ len ]; > int cnt; > int off = 0; > while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { > off += cnt; > } > > This keeps you from adding -1 to pos when the read returns -1. It > also skips > out when the read is 0 bytes which, is not a described EOF in > InputStream java > docs, but is a condition I want to be aware of. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Mar 6 14:47:44 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 Mar 2007 14:47:44 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: Just FYI, rxtx will usually not break out on EINTER. The code in the native library usually does something close to this: do { read(...) } while ( !done && errno==EINTR ); Obviously there is a little more involved but it will retry on EINTER if not done. On Tue, 6 Mar 2007, Joachim Buechse wrote: > The code I copied was from a file resource reader, it shouldn't > really be applied to networking/external IO code. Mea culpa. > > However aborting when you get 0 from read is not always what you want > either (you kind of indicated that already). Some unix java > implementations will return 0 if the kernel read was aborted with > EINTER, which is rarely the point where you want to abort your read - > at least not without further checks. A "complete" solution always > depends on the events you need to handle and the time the total read > could take in reality. In some cases it's worth checking > Thread.isInterrupted() in the loop, some code re-loops on 0 but only > a limited number of times, some check a total timeout limit, etc... > > Best regards, > Joachim > > On 05.03.2007, at 15:25, Gregg Wonderly wrote: >> My preferred structure is. >> >> byte arr[ len ]; >> int cnt; >> int off = 0; >> while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { >> off += cnt; >> } >> >> This keeps you from adding -1 to pos when the read returns -1. It >> also skips >> out when the read is 0 bytes which, is not a described EOF in >> InputStream java >> docs, but is a condition I want to be aware of. >> >> Gregg Wonderly >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 gjhanna at gmail.com Thu Mar 8 13:42:52 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Fri, 9 Mar 2007 09:42:52 +1300 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? Message-ID: I've just struck an issue using rxtx in a multi-threaded environment: If I have 3 threads trying to open *the same* comm-port I get a deadlock in CommPortIdentifier.open If I have just 2, it works fine - I get a PortInUseException which is nice and I can handle it. The 3 thread->deadlock thing is causing me issues. (Sample code below). This is from the java thread-dump Found one Java-level deadlock: ============================= "Thread-2": waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object ), which is held by "Thread-1" "Thread-1": waiting to lock monitor 0x0003e9cc (object 0x2450e108, a gnu.io.CommPortIdentifier), which is held by "Thread-2" Java stack information for the threads listed above: =================================================== "Thread-2": at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:329) - waiting to lock <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) "Thread-1": at java.lang.Object.wait(Native Method) - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) - locked <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) (Apart from this, rxtx is working fantastically for us). I'm thinking I'll have to implement some sort of locking mechanism that *doesn't* use java synchronization to prevent this situation. (Which doesn't sound like a good idea to me). Any ideas? Thanks, Greg Hanna ============= RXTXLockTest.java ======================================== import gnu.io.CommPort; import gnu.io.CommPortIdentifier; /** * @author Greg Hanna * Minimal code to create a deadlock with rxtx in multithreaded open */ public class RXTXLockTest { public static void main(String[] args) { try { CommPortIdentifier cpiCom1 = CommPortIdentifier.getPortIdentifier ("COM14"); OpenThread t1 = new OpenThread (" one ", cpiCom1); OpenThread t2 = new OpenThread (" two ", cpiCom1); OpenThread t3 = new OpenThread (" 003 ", cpiCom1); t1.start(); t2.start(); t3.start(); // comment this out and it runs with (expected) PortInUseException } catch (Exception e) { e.printStackTrace(); } } } class OpenThread extends Thread { String name; CommPortIdentifier cpi; CommPort cp; public OpenThread (String name, CommPortIdentifier cpi) { this.name = name; this.cpi = cpi; System.out.println (System.currentTimeMillis() + name + " thread created"); } public void run () { try { System.out.println (System.currentTimeMillis() + name + " opening"); cp = cpi.open(name, 2000); System.out.println (System.currentTimeMillis() + name + " opened - sleeping"); sleep (2000); // do the serial comms with the device. System.out.println (System.currentTimeMillis() + name + " slept - closing"); cp.close(); System.out.println (System.currentTimeMillis() + name + " closed - exiting"); } catch (Exception e) { System.out.println ("Error in thread: " + name ); e.printStackTrace(); } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070308/d9a163c5/attachment-0003.html From eu259473 at tele2.it Fri Mar 9 02:46:20 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 09 Mar 2007 10:46:20 +0100 Subject: [Rxtx] rxtx: tru64 unix make fails Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070309/3b654523/attachment-0003.html From lyon at docjava.com Fri Mar 9 03:58:32 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 Mar 2007 05:58:32 -0500 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi All, The deadlock issue is one that I have been thinking about for some time now. It seems to me that we need a resource manager that enables assignment to a known process. The one thing that seems important about serial ports is that two applications should not use the same serial port at the same time. When this happens, it throws an exception. OK. The exception is a response to a lock condition that arises from an unavailable resource. An abstract implementation (not born of native methods) might assign a serial port to an application, until the application releases it (or is forced to release it by some kill mechanism). Some resources (like a registry) can be reused. But others, like the serial port, cannot. In the case of the serial port, we would like, I think, to have the flyweight design pattern without sharing and with object assignment tracking. A means of breaking deadlock (like a leasing mechanism) seems very useful, to me. My guess is that we can serialize the state of the Parametric Singleton Pattern (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) into the Preferences of the System. Preferences.systemRoot() might help with that. When a resource is checked out, the lease time and owner are listed. A thread that does this can be killed, but applications outside of Java are problematic. There is a compelling problem here. It is not just serial ports. Sound cards, cameras, microphones, files, tape drives, etc. All are consumed resources that are assigned to an application (or user) and deprive other applications, or users, from use. What, if anything, should we do? At present we throw PortInUseExceptions. Is that it? Can we do better? OK, the port is in use. Now what? Do I have to be root to go remove lock files and kill applications? Is there a better way? Thanks! - Doug >I've just struck an issue using rxtx in a multi-threaded environment: > >If I have 3 threads trying to open *the same* >comm-port I get a deadlock in >CommPortIdentifier.open >If I have just 2, it works fine - I get a >PortInUseException which is nice and I can >handle it. > >The 3 thread->deadlock thing is causing me issues. >(Sample code below). > >This is from the java thread-dump > >Found one Java-level deadlock: >============================= >"Thread-2": > waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), > which is held by "Thread-1" >"Thread-1": > waiting to lock monitor 0x0003e9cc (object >0x2450e108, a gnu.io.CommPortIdentifier ), > which is held by "Thread-2" > >Java stack information for the threads listed above: >=================================================== >"Thread-2": > at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) > - waiting to lock <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) >"Thread-1": > at java.lang.Object.wait(Native Method) > - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) > - locked <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) > > >(Apart from this, rxtx is working fantastically for us). > >I'm thinking I'll have to implement some sort of >locking mechanism that *doesn't* use java >synchronization to prevent this situation. >(Which doesn't sound like a good idea to me). > >Any ideas? > >Thanks, > >Greg Hanna > >============= RXTXLockTest.java ======================================== > >import gnu.io.CommPort; >import gnu.io.CommPortIdentifier; > >/** > * @author Greg Hanna > * Minimal code to create a deadlock with rxtx in multithreaded open > */ >public class RXTXLockTest { > ? > ?public static void main(String[] args) { > ?try { > ?CommPortIdentifier cpiCom1 = >CommPortIdentifier.getPortIdentifier ("COM14"); > ?OpenThread t1 = new OpenThread (" one ", cpiCom1); > ?OpenThread t2 = new OpenThread (" two ", cpiCom1); > ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); > ?t1.start(); > ?t2.start(); > ?t3.start(); // comment this out >and it runs with (expected) PortInUseException > ?} catch (Exception e) { > ?e.printStackTrace(); > ?} > ?} >} > >class OpenThread extends Thread { > ?String name; > ?CommPortIdentifier cpi; > ?CommPort cp; > ?public OpenThread (String name, CommPortIdentifier cpi) { > ? this.name = name; > ?this.cpi = cpi; > ?System.out.println >(System.currentTimeMillis() + name + " thread >created"); > ?} > ?public void run () { > ?try { > ?System.out.println >(System.currentTimeMillis() + name + " opening"); > ?cp = cpi.open(name, 2000); > ?System.out.println >(System.currentTimeMillis() + name + " opened - >sleeping"); > ?sleep (2000); // do the serial comms with the device. > ?System.out.println >(System.currentTimeMillis() + name + " slept - >closing"); > ?cp.close(); > ?System.out.println >(System.currentTimeMillis() + name + " closed - >exiting"); > ?} catch (Exception e) { > System.out.println ("Error in thread: " + name ); > ?e.printStackTrace(); > ?} > ?} >} > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Mar 9 06:37:45 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 Mar 2007 06:37:45 -0700 (MST) Subject: [Rxtx] rxtx: tru64 unix make fails In-Reply-To: References: Message-ID: On Fri, 9 Mar 2007, "Giuseppe Marchese" wrote: > Sorry for delay. > ? > This is log for ./configure and make > error. > ? > thanks for attention > ? > Make: '%.java,$(TOP)/$(CLASSDEST)/%.class,$(wildcard $(SPATH)/*.java)': extra chars.? > Stop. > Hi Giuseppe You need to use GNU make with the Makefile. I suspect the tru64 make is not happy with those rules. > configure: exit 0 Looks like configure is fairly happy. From tjarvi at qbang.org Sat Mar 10 07:43:51 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 07:43:51 -0700 (MST) Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi Doug I have very little time to look into this further but what we could do is open up an rxtx 3 devel branch in which a proof of concept could be worked on. It could be the proof of concept for a JSR others including Sun could look at/work on or parts of it could be recycled in a JSR. I'm working very hard on rxtx right now but it does not show. I'm looking at win64, mac intel/ppc, usb bluetooth and usb serial dongles. Some are going to be more tested than others but they are all on the plate. I'll be pushing all the fixes upstream when they are done. So I'm very busy in 2.1 but we could open a new branch. On Fri, 9 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > The deadlock issue is one that I have been thinking about > for some time now. > It seems to me that we need a resource manager that enables assignment > to a known process. > > The one thing that seems important about serial > ports is that two applications should not use the > same serial port at the same time. When this > happens, it throws an exception. > OK. > > The exception is a response to a lock condition that > arises from an unavailable resource. > > An abstract implementation (not born of native methods) might > assign a serial port to an application, until the > application releases it (or is forced to release > it by some kill mechanism). > > Some resources (like a registry) can be reused. > But others, like the serial port, > cannot. > > In the case of the serial port, we would like, I think, to > have the flyweight design pattern > without sharing and with object assignment tracking. > A means of breaking deadlock (like a leasing > mechanism) seems very useful, to me. > > My guess is that we can serialize the state of the Parametric Singleton Pattern > (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) > into the Preferences of the System. Preferences.systemRoot() might help > with that. When a resource is checked out, the lease time and owner are > listed. A thread that does this can be killed, but applications outside of Java > are problematic. > > There is a compelling problem here. It is not just serial ports. > Sound cards, cameras, microphones, files, tape drives, etc. All are consumed > resources that are assigned to an application (or > user) and deprive other applications, > or users, from use. > > What, if anything, should we do? At present we throw PortInUseExceptions. > Is that it? > Can we do better? > OK, the port is in use. Now what? > Do I have to be root to go remove lock files and kill applications? > Is there a better way? > > Thanks! > - Doug > >> I've just struck an issue using rxtx in a multi-threaded environment: >> >> If I have 3 threads trying to open *the same* >> comm-port I get a deadlock in >> CommPortIdentifier.open >> If I have just 2, it works fine - I get a >> PortInUseException which is nice and I can >> handle it. >> >> The 3 thread->deadlock thing is causing me issues. >> (Sample code below). >> >> This is from the java thread-dump >> >> Found one Java-level deadlock: >> ============================= >> "Thread-2": >> waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), >> which is held by "Thread-1" >> "Thread-1": >> waiting to lock monitor 0x0003e9cc (object >> 0x2450e108, a gnu.io.CommPortIdentifier ), >> which is held by "Thread-2" >> >> Java stack information for the threads listed above: >> =================================================== >> "Thread-2": >> at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) >> - waiting to lock <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> "Thread-1": >> at java.lang.Object.wait(Native Method) >> - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) >> - locked <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> >> >> (Apart from this, rxtx is working fantastically for us). >> >> I'm thinking I'll have to implement some sort of >> locking mechanism that *doesn't* use java >> synchronization to prevent this situation. >> (Which doesn't sound like a good idea to me). >> >> Any ideas? >> >> Thanks, >> >> Greg Hanna >> >> ============= RXTXLockTest.java ======================================== >> >> import gnu.io.CommPort; >> import gnu.io.CommPortIdentifier; >> >> /** >> * @author Greg Hanna >> * Minimal code to create a deadlock with rxtx in multithreaded open >> */ >> public class RXTXLockTest { >> ? >> ?public static void main(String[] args) { >> ?try { >> ?CommPortIdentifier cpiCom1 = >> CommPortIdentifier.getPortIdentifier ("COM14"); >> ?OpenThread t1 = new OpenThread (" one ", cpiCom1); >> ?OpenThread t2 = new OpenThread (" two ", cpiCom1); >> ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); >> ?t1.start(); >> ?t2.start(); >> ?t3.start(); // comment this out >> and it runs with (expected) PortInUseException >> ?} catch (Exception e) { >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> class OpenThread extends Thread { >> ?String name; >> ?CommPortIdentifier cpi; >> ?CommPort cp; >> ?public OpenThread (String name, CommPortIdentifier cpi) { >> ? this.name = name; >> ?this.cpi = cpi; >> ?System.out.println >> (System.currentTimeMillis() + name + " thread >> created"); >> ?} >> ?public void run () { >> ?try { >> ?System.out.println >> (System.currentTimeMillis() + name + " opening"); >> ?cp = cpi.open(name, 2000); >> ?System.out.println >> (System.currentTimeMillis() + name + " opened - >> sleeping"); >> ?sleep (2000); // do the serial comms with the device. >> ?System.out.println >> (System.currentTimeMillis() + name + " slept - >> closing"); >> ?cp.close(); >> ?System.out.println >> (System.currentTimeMillis() + name + " closed - >> exiting"); >> ?} catch (Exception e) { >> System.out.println ("Error in thread: " + name ); >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 mm at UDel.Edu Sat Mar 10 14:48:32 2007 From: mm at UDel.Edu (Mike Markowski) Date: Sat, 10 Mar 2007 16:48:32 -0500 Subject: [Rxtx] rxtx and Sun's comm api Message-ID: <45F327B0.2060004@udel.edu> Hi all, I joined the list a few days ago and apologize for what is likely a frequently asked question, though I haven't yet found it anywhere. I learned about rxtx.org through the readme on Sun's version 2 of their comms api. They give recommendations in that readme regarding how a better comms api should be written. Is this the aim of rxtx.org? I wrote an app on my linux box using the Sun comms api (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the fact that only linux and Solaris are supported. So I'm glad to find rxtx.org and am just reading up on how make the conversion so Windows users will be able to run the program as well. At the same time I'm just curious if rxtx.org and Sun are both heading in the same direction. Thanks for any background or historical info. Feel free to point me to any www pages if my googling has just completely missed the target! Thanks again, Mike From tjarvi at qbang.org Sat Mar 10 15:35:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 15:35:25 -0700 (MST) Subject: [Rxtx] rxtx and Sun's comm api In-Reply-To: <45F327B0.2060004@udel.edu> References: <45F327B0.2060004@udel.edu> Message-ID: On Sat, 10 Mar 2007, Mike Markowski wrote: > Hi all, > > I joined the list a few days ago and apologize for what is likely a > frequently asked question, though I haven't yet found it anywhere. I > learned about rxtx.org through the readme on Sun's version 2 of their > comms api. They give recommendations in that readme regarding how a > better comms api should be written. Is this the aim of rxtx.org? > > I wrote an app on my linux box using the Sun comms api > (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the > fact that only linux and Solaris are supported. So I'm glad to find > rxtx.org and am just reading up on how make the conversion so Windows > users will be able to run the program as well. At the same time I'm > just curious if rxtx.org and Sun are both heading in the same direction. > > Thanks for any background or historical info. Feel free to point me to > any www pages if my googling has just completely missed the target! > I do not have any news (good or bad) concerning RXTX and Sun working together but perhaps others here do. The main goal of RXTX is to expose POSIX termios interfaces to java users. The future support of javax.comm is questionable. We do not have resources for everything. gnu.io (RXTX 2.1) will be supported going forward and functions the same as CommAPI 2.0. If you have control of the source code you are working with, I would not advise using CommAPI 2.0 javax.comm. We do support CommAPI 2.0 javax.comm for older applications but I do not think that will last much longer for practical reasons. The download interest in CommAPI 2.0 javax.comm support is becomming negligible on this end. There has been discussion of a JSR effort but I do not know of any status change since it was mentioned. One problem with a JSR is that even a light weight process is going to be difficult for RXTX at this time. Maybe that will change in the future but then again it may not. For now, we are just going forward 'as is' in rxtx 2.1 with package gnu.io while trying as a secondary effort to backport the changes to rxtx 2.0 for javax.comm support for users that do not have a choice. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Mar 11 07:19:40 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 11 Mar 2007 08:19:40 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: Hi All, I have been a proponent of a JSR that makes use of RXTX. I have executed the proper agreements with Sun. At this point we are in the: Early Draft Review of Draft Specifications Stage. The best thing to do is to enter the quiet period and create a specification. The question of exactly how we, as a group, want to approach this problem, remains open. Typically, we should have both a specification and a reference implementation. Thus, it would be to our best advantage to have a nice, stable, cross platform RXTX distro that adheres to the groups specification. Now, from a specification standpoint, my personal view on the matter is that we create a series of interfaces, with nice documentation (or at least javadoc). Is this a good idea? Should we have a pure interface specification for the communication API? There are several issues, in my mind, which still weigh on us. Hot-pluggable dongles, long discovery process on pop-up ports, lack of uniformity on device names, lack of uniformity on locking, a precise understanding of how the SerialPortResourceManager works (or even if we should have one). The more questions we answer in our reference implementation, the better our specification will get. RXTX is a good working prototype, but, I don't know if that is what we want to use for a specification. Here is what I have for a CommPortInterface: */ public interface CommPortInterface { /** * @return a string representation of this port. */ String toString(); /** * Gets the name of the communications port. This name should correspond to * something the user can identify, like the label on the hardware. * @return name of the port */ String getName(); /** * @return an input stream that can be used to read data from the * communications port. If the port doesn't support reading data, this * method returns null. *

* The blocking behaviour of this input stream depends on the threshold * and timeout values, as shown below for a read buffer size of n * bytes: * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ThresholdTimeoutBlocking behaviour
StateValueStateValue
disableddisabledblock until data is available
enabledm bytesdisabledblock until min(m, n) bytes are available
disabledenabledt msblock for t ms or until data is available
enabledm bytesenabledt msblock for t ms or until min(m, n) bytes are * available
* @throws java.io.IOException */ InputStream getInputStream() throws IOException; /** * @return an output stream that can be used to send data to the * communications port. If the port doesn't support sending data, this * method returns null. * @throws java.io.IOException */ OutputStream getOutputStream() throws IOException; /** * Closes this communications port. * All PortOwnershipListeners will be? * notified of this change of ownership. Further method calls on this? * object will throw IllegalStateException. Further calls on the? * associated InputStream or OutputStream will throw IOException. *

* Close does not block. Undelivered data is discarded. Blocked read and? * write operations are aborted if the underlying operating systems? * supports an IO abort mechanism. To await the delivery of undelivered? * data call OutputStream.flush() or OutputStream.close() before calling? * Port.close(). */ void close(); /** * Enables receive threshold. * When the specified threshold number of bytes are retrieved, read will * return immediately. * * @param thresh the number of bytes in the input buffer * @throws gnu.io.UnsupportedCommOperationException * if receive threshold is * not supported by the driver * @see #disableReceiveThreshold */ void enableReceiveThreshold(int thresh) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive threshold. * * @see #enableReceiveThreshold */ void disableReceiveThreshold(); /** * @return true if receive threshold is enabled. * * @see #enableReceiveThreshold */ boolean isReceiveThresholdEnabled(); /** * @return the receive threshold value. If receive threshold is diabled * or not supported, this value is meaningless. * * @see #enableReceiveThreshold */ int getReceiveThreshold(); /** * Enables receive timeout. * When the specified number of milliseconds have elapsed, read will * return immediately. * * @param rcvTimeout the number of milliseconds to block for * @throws gnu.io.UnsupportedCommOperationException * if receive timeout is * not supported by the driver * @see #disableReceiveTimeout */ void enableReceiveTimeout(int rcvTimeout) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive timeout. * * @see #enableReceiveTimeout */ void disableReceiveTimeout(); /** * @return true if receive timeout is enabled. * * @see #enableReceiveTimeout */ boolean isReceiveTimeoutEnabled(); /** * @return the receive timeout value. If receive timeout is diabled * or not supported, this value is meaningless. * * @see #enableReceiveTimeout */ int getReceiveTimeout(); /** * Enables receive framing. * The supplied byte value in the input suggests the end of the received * frame, and read returns immediately. Only the low 8 bits of the * supplied value are significant. * * @param framingByte the frame delimiter * @throws gnu.io.UnsupportedCommOperationException * if receive framing is * not supported by the driver * @see #disableReceiveFraming */ void enableReceiveFraming(int framingByte) throws UnsupportedCommOperationException; /** * Disables receive framing. * * @see #enableReceiveFraming */ void disableReceiveFraming(); /** * @return true if receive framing is enabled. * * @see #enableReceiveFraming */ boolean isReceiveFramingEnabled(); /** * @return true if receive framing byte. If receive framing is diabled * or not supported, this value is meaningless. * * @see #enableReceiveFraming */ int getReceiveFramingByte(); /** * Sets the input buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setInputBufferSize(int size); /** * @return the input buffer size. * The driver may choose not to report correct values. */ int getInputBufferSize(); /** * Sets the output buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setOutputBufferSize(int size); /** * @return the output buffer size. * The driver may choose not to report correct values. */ int getOutputBufferSize(); } What do you think of that? Note the wishy washy nature of the spec: The driver may choose to ignore this method. Is that good enough for us? Thanks! - Doug From ra85551 at gmail.com Sun Mar 11 08:44:45 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Sun, 11 Mar 2007 17:44:45 +0300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hello, world! I am writing application that communicates with modem via AT commands. My OS is Linux Kubuntu Feisty Herd, to ensure that my application will run properly under Windows XP I installed VMWare server. When I tried to send AT command and evaluate modem answer under WinXP @ VMWare server, I actually didn't receive anything. I think that VM settings are right, because I do can communicate with modem by using standard HyperTerminall as well as I can do on native Windows. So, why RXTX doesn't work under VM, but works under Linux and pure Windows XP (i tested it there) well? The send/receive method code follows. private String sendATCommand(String command, final String waitFor, final boolean isRegex, boolean isAddCRLF, long timeout) throws BeaconConnectException { final long POLL_PERIOD = 100; final int BUFFER_SIZE = 512; final byte[] buffer = new byte[BUFFER_SIZE]; final InputStream serialInput; final OutputStream serialOutput; try { serialInput = serialPort.getInputStream(); if (command != null) { serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } } catch (IOException e) { throw new MyException("serial I/O error"); } TimerTask task = new TimerTask() { int offset = 0; int bytesRead; public synchronized void run() { try { if (serialInput.available() > 0) { bytesRead = serialInput.read(buffer, offset, BUFFER_SIZE - offset); } else { return; } } catch (IOException e) { // do nothing - maybe next time we'll read something } offset += bytesRead; if (waitFor != null) { String temporary = new String(buffer, 0, offset).trim(); if (isRegex && temporary.matches(waitFor) || temporary.contains(waitFor)) { cancel(); notify(); } } } }; Timer timer = new Timer(); timer.schedule(task, POLL_PERIOD, POLL_PERIOD); synchronized (task) { try { task.wait(timeout); task.cancel(); } catch (InterruptedException e) { } } //Cut off leading and trailing CRs, LFs and zeroes String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); System.out.println(response); return response; } -- Pavel Parkhomenko From tjarvi at qbang.org Sun Mar 11 11:48:22 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:48:22 -0600 (MDT) Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: On Sun, 11 Mar 2007, Pavel Parkhomenko wrote: > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. > > private String sendATCommand(String command, final String waitFor, > final boolean isRegex, boolean isAddCRLF, long timeout) > throws BeaconConnectException > { > final long POLL_PERIOD = 100; > final int BUFFER_SIZE = 512; > final byte[] buffer = new byte[BUFFER_SIZE]; > final InputStream serialInput; > final OutputStream serialOutput; > try > { > serialInput = serialPort.getInputStream(); > if (command != null) > { > serialOutput = serialPort.getOutputStream(); > if (isAddCRLF) > { > command += "\r\n"; > } > System.out.println(command); > serialOutput.write(command.getBytes()); > } > } > catch (IOException e) > { > throw new MyException("serial I/O error"); > } > > TimerTask task = new TimerTask() > { > int offset = 0; > int bytesRead; > public synchronized void run() > { > try > { > if (serialInput.available() > 0) > { > bytesRead = serialInput.read(buffer, offset, > BUFFER_SIZE - offset); > } > else > { > return; > } > } > catch (IOException e) > { > // do nothing - maybe next time we'll read something > } > offset += bytesRead; > if (waitFor != null) > { > String temporary = new String(buffer, 0, offset).trim(); > if (isRegex && temporary.matches(waitFor) || > temporary.contains(waitFor)) > { > cancel(); > notify(); > } > } > } > }; > > Timer timer = new Timer(); > timer.schedule(task, POLL_PERIOD, POLL_PERIOD); > synchronized (task) { > try > { > task.wait(timeout); > task.cancel(); > } > catch (InterruptedException e) > { > } > } > //Cut off leading and trailing CRs, LFs and zeroes > String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); > System.out.println(response); > return response; > } > > > Hi Pavel VMWare should not be a problem. I've used it in the past - though not with a modem. Make sure nothing else is using the modem. Then look in the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an example that should work. Note that modems could care less what OS is on top. If you are trying to match new lines to the OS and sending it to the mode for AT commands, thats probably a mistake. Also it would not hurt to print out the individual bytes that you are sending to make sure they did not get mangled along the path. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 11:55:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:55:48 -0600 (MDT) Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: On Sun, 11 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > I have been a proponent of a JSR that makes > use of RXTX. I have executed the proper agreements with Sun. > > At this point we are in the: > Early Draft Review of Draft Specifications Stage. > > The best thing to do is to enter the quiet period and create > a specification. The question of exactly how we, as a group, > want to approach this problem, remains open. > > Typically, we should have both a specification and a reference > implementation. Thus, it would be to our best advantage to have > a nice, stable, cross platform RXTX distro that adheres to the > groups specification. > > Now, from a specification standpoint, my personal view on the matter is > that we create a series of interfaces, with nice documentation (or at least > javadoc). > > Is this a good idea? Should we have a pure interface specification for > the communication API? > > There are several issues, in my mind, which still weigh on us. > Hot-pluggable dongles, long discovery process on pop-up ports, > lack of uniformity on device names, lack of uniformity on locking, > a precise understanding of how the SerialPortResourceManager > works (or even if we should have one). > > The more questions we answer in our reference implementation, the > better our specification will get. RXTX is a good working prototype, > but, I don't know if that is what we want to use for a specification. > > Here is what I have for a CommPortInterface: > */ > public interface CommPortInterface { Hi Doug, I can start going through the method interfaces later this week and giving feedback. I would suggest that the JSR should not be too generic in nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel drivers that intend to look like EIA232 ports at the kernel driver level. some ideas: EIA232PortInterface TermiosInterface SerialPortInterface Something that differentiates this from thing like USB, I2C, ... which should not have to deal with legacy serial claiming to be the comm api. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 12:52:19 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 12:52:19 -0600 (MDT) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: No news is good news with these posts. I'll start the process of pinging legal a week from Monday on my end if nobody has objections to the proposal. I just want to make sure everyone has time to raise objections. Obviously, anyone can fork from a previous version if they don't like the new license. I suspect we can avoid that though. On Sun, 4 Mar 2007, Trent Jarvi wrote: > > For those that are wondering what is going on here, this > next bit is the meat of the changes. We agreed a long time > ago to put this disclaimer in. We did a so so job. It was > in rxtx 2.0, not well written, ... So some groups using > rxtx that would like to ship rxtx so users don't need to > download, install, go to the mail-list to find why it failed, > ... Then their legal teams tell them section 5 paragraph 2 > is a show stopper. > > That was never the intent. > > > Now going through what remains... > >> and might need a (TM) suffix to make Sun happy. > > Added disclaimer at the ended 'all trademarks belong...' > >> * Line #15ff - static vs. dynamic linking - you did >> not transcribe the text from the "controlled >> interface exception" when writing this text - and >> this was good so, because these terms originally >> refer to the GPL rather than the LGPL. I think though, >> that these 4 lines are the most important ones and >> should thus be really really clear. I hope that I >> meet your original intent with the following >> suggestions: >> 1.) Instead of "A program.." it would be better to >> say "An exectuable.." in order to be closer to >> the LGPL text. > > OK. As you can see I was trying to adjust GNU text there > for the LGPL. > >> 2.) It would be better to say .. "by being dynamically >> linked with it" to clearly indicate that dynamic >> linking is meant. The matter of compilation is >> already covered by the LGPL so mentioning it again >> just leads to confusion. > > used dynamically linked terminology. > >> 3.) It would be better to say .. "is considered a >> work that uses the library in contrast to section >> 5 of the LGPL, so the terms of the LGPL do not >> apply to the resulting executable". > > I tried to address this more upfront with an intent statement. > Let me know if you have problems with it. I also tried to > make it a little more clear what was derived from the GNU > solution by moving the link location closer to GNU's suggestion. > >> >> Note that LGPL section 5 says: ..."is called a >> "work that uses the Library". Such a work, in isolation, >> is not a derivative work of the Library, and therefore >> falls outside the scope of this License." >> The next paragraph of the LGPL is exactly the problematic >> one that I hope is clarified by the exception terms you >> give. >> > > Thats the intent. Here is the combined fixes. Note that only the > material in /*-- --*/ is being touched. The new GPL license is > there but unmodified. > > > ------------------------ begin proposed new license ------------------- > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Lesser General Public > | License as published by the Free Software Foundation; either > | version 2.1 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Lesser General Public License for more details. > | > | An executable that contains no derivative of any portion of RXTX, but > | is designed to work with RXTX by being dynamically linked with it, > | is considered a "work that uses the Library" subject to the terms and > | conditions of the GNU Lesser General Public License. > | > | The following has been added to the RXTX License to remove > | any confusion about linking to RXTX. We want to allow in part what > | section 5, paragraph 2 of the LGPL does not permit in the special > | case of linking over a controlled interface. The intent is to add a > | Java Specification Request or standards body defined interface in the > | future as another exception but one is not currently available. > | > | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface > | > | As a special exception, the copyright holders of RXTX give you > | permission to link RXTX with independent modules that communicate with > | RXTX solely through the Sun Microsytems CommAPI interface version 2, > | regardless of the license terms of these independent modules, and to copy > | and distribute the resulting combined work under terms of your choice, > | provided that every copy of the combined work is accompanied by a complete > | copy of the source code of RXTX (the version of RXTX used to produce the > | combined work), being distributed under the terms of the GNU Lesser General > | Public License plus this exception. An independent module is a > | module which is not derived from or based on RXTX. > | > | Note that people who make modified versions of RXTX are not obligated > | to grant this special exception for their modified versions; it is > | their choice whether to do so. The GNU Lesser General Public License > | gives permission to release a modified version without this exception; this > | exception also makes it possible to release a modified version which > | carries forward this exception. > | > | You should have received a copy of the GNU Lesser General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > | All trademarks belong to their respective owners. > --------------------------------------------------------------------------*/ > > The original GNU Lesser General Public License Follows. > > > GNU LESSER GENERAL PUBLIC LICENSE > Version 2.1, February 1999 > > Copyright (C) 1991, 1999 Free Software Foundation, Inc. > 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > Everyone is permitted to copy and distribute verbatim copies > of this license document, but changing it is not allowed. > > [This is the first released version of the Lesser GPL. It also counts > as the successor of the GNU Library Public License, version 2, hence > the version number 2.1.] > > Preamble > > The licenses for most software are designed to take away your > freedom to share and change it. By contrast, the GNU General Public > Licenses are intended to guarantee your freedom to share and change > free software--to make sure the software is free for all its users. > > This license, the Lesser General Public License, applies to some > specially designated software packages--typically libraries--of the > Free Software Foundation and other authors who decide to use it. You > can use it too, but we suggest you first think carefully about whether > this license or the ordinary General Public License is the better > strategy to use in any particular case, based on the explanations below. > > When we speak of free software, we are referring to freedom of use, > not price. Our General Public Licenses are designed to make sure that > you have the freedom to distribute copies of free software (and charge > for this service if you wish); that you receive source code or can get > it if you want it; that you can change the software and use pieces of > it in new free programs; and that you are informed that you can do > these things. > > To protect your rights, we need to make restrictions that forbid > distributors to deny you these rights or to ask you to surrender these > rights. These restrictions translate to certain responsibilities for > you if you distribute copies of the library or if you modify it. > > For example, if you distribute copies of the library, whether gratis > or for a fee, you must give the recipients all the rights that we gave > you. You must make sure that they, too, receive or can get the source > code. If you link other code with the library, you must provide > complete object files to the recipients, so that they can relink them > with the library after making changes to the library and recompiling > it. And you must show them these terms so they know their rights. > > We protect your rights with a two-step method: (1) we copyright the > library, and (2) we offer you this license, which gives you legal > permission to copy, distribute and/or modify the library. > > To protect each distributor, we want to make it very clear that > there is no warranty for the free library. Also, if the library is > modified by someone else and passed on, the recipients should know > that what they have is not the original version, so that the original > author's reputation will not be affected by problems that might be > introduced by others. > > Finally, software patents pose a constant threat to the existence of > any free program. We wish to make sure that a company cannot > effectively restrict the users of a free program by obtaining a > restrictive license from a patent holder. Therefore, we insist that > any patent license obtained for a version of the library must be > consistent with the full freedom of use specified in this license. > > Most GNU software, including some libraries, is covered by the > ordinary GNU General Public License. This license, the GNU Lesser > General Public License, applies to certain designated libraries, and > is quite different from the ordinary General Public License. We use > this license for certain libraries in order to permit linking those > libraries into non-free programs. > > When a program is linked with a library, whether statically or using > a shared library, the combination of the two is legally speaking a > combined work, a derivative of the original library. The ordinary > General Public License therefore permits such linking only if the > entire combination fits its criteria of freedom. The Lesser General > Public License permits more lax criteria for linking other code with > the library. > > We call this license the "Lesser" General Public License because it > does Less to protect the user's freedom than the ordinary General > Public License. It also provides other free software developers Less > of an advantage over competing non-free programs. These disadvantages > are the reason we use the ordinary General Public License for many > libraries. However, the Lesser license provides advantages in certain > special circumstances. > > For example, on rare occasions, there may be a special need to > encourage the widest possible use of a certain library, so that it becomes > a de-facto standard. To achieve this, non-free programs must be > allowed to use the library. A more frequent case is that a free > library does the same job as widely used non-free libraries. In this > case, there is little to gain by limiting the free library to free > software only, so we use the Lesser General Public License. > > In other cases, permission to use a particular library in non-free > programs enables a greater number of people to use a large body of > free software. For example, permission to use the GNU C Library in > non-free programs enables many more people to use the whole GNU > operating system, as well as its variant, the GNU/Linux operating > system. > > Although the Lesser General Public License is Less protective of the > users' freedom, it does ensure that the user of a program that is > linked with the Library has the freedom and the wherewithal to run > that program using a modified version of the Library. > > The precise terms and conditions for copying, distribution and > modification follow. Pay close attention to the difference between a > "work based on the library" and a "work that uses the library". The > former contains code derived from the library, whereas the latter must > be combined with the library in order to run. > > GNU LESSER GENERAL PUBLIC LICENSE > TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION > > 0. This License Agreement applies to any software library or other > program which contains a notice placed by the copyright holder or > other authorized party saying it may be distributed under the terms of > this Lesser General Public License (also called "this License"). > Each licensee is addressed as "you". > > A "library" means a collection of software functions and/or data > prepared so as to be conveniently linked with application programs > (which use some of those functions and data) to form executables. > > The "Library", below, refers to any such software library or work > which has been distributed under these terms. A "work based on the > Library" means either the Library or any derivative work under > copyright law: that is to say, a work containing the Library or a > portion of it, either verbatim or with modifications and/or translated > straightforwardly into another language. (Hereinafter, translation is > included without limitation in the term "modification".) > > "Source code" for a work means the preferred form of the work for > making modifications to it. For a library, complete source code means > all the source code for all modules it contains, plus any associated > interface definition files, plus the scripts used to control compilation > and installation of the library. > > Activities other than copying, distribution and modification are not > covered by this License; they are outside its scope. The act of > running a program using the Library is not restricted, and output from > such a program is covered only if its contents constitute a work based > on the Library (independent of the use of the Library in a tool for > writing it). Whether that is true depends on what the Library does > and what the program that uses the Library does. > > 1. You may copy and distribute verbatim copies of the Library's > complete source code as you receive it, in any medium, provided that > you conspicuously and appropriately publish on each copy an > appropriate copyright notice and disclaimer of warranty; keep intact > all the notices that refer to this License and to the absence of any > warranty; and distribute a copy of this License along with the > Library. > > You may charge a fee for the physical act of transferring a copy, > and you may at your option offer warranty protection in exchange for a > fee. > > 2. You may modify your copy or copies of the Library or any portion > of it, thus forming a work based on the Library, and copy and > distribute such modifications or work under the terms of Section 1 > above, provided that you also meet all of these conditions: > > a) The modified work must itself be a software library. > > b) You must cause the files modified to carry prominent notices > stating that you changed the files and the date of any change. > > c) You must cause the whole of the work to be licensed at no > charge to all third parties under the terms of this License. > > d) If a facility in the modified Library refers to a function or a > table of data to be supplied by an application program that uses > the facility, other than as an argument passed when the facility > is invoked, then you must make a good faith effort to ensure that, > in the event an application does not supply such function or > table, the facility still operates, and performs whatever part of > its purpose remains meaningful. > > (For example, a function in a library to compute square roots has > a purpose that is entirely well-defined independent of the > application. Therefore, Subsection 2d requires that any > application-supplied function or table used by this function must > be optional: if the application does not supply it, the square > root function must still compute square roots.) > > These requirements apply to the modified work as a whole. If > identifiable sections of that work are not derived from the Library, > and can be reasonably considered independent and separate works in > themselves, then this License, and its terms, do not apply to those > sections when you distribute them as separate works. But when you > distribute the same sections as part of a whole which is a work based > on the Library, the distribution of the whole must be on the terms of > this License, whose permissions for other licensees extend to the > entire whole, and thus to each and every part regardless of who wrote > it. > > Thus, it is not the intent of this section to claim rights or contest > your rights to work written entirely by you; rather, the intent is to > exercise the right to control the distribution of derivative or > collective works based on the Library. > > In addition, mere aggregation of another work not based on the Library > with the Library (or with a work based on the Library) on a volume of > a storage or distribution medium does not bring the other work under > the scope of this License. > > 3. You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. To do > this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version 2, > instead of to this License. (If a newer version than version 2 of the > ordinary GNU General Public License has appeared, then you can specify > that version instead if you wish.) Do not make any other change in > these notices. > > Once this change is made in a given copy, it is irreversible for > that copy, so the ordinary GNU General Public License applies to all > subsequent copies and derivative works made from that copy. > > This option is useful when you wish to copy part of the code of > the Library into a program that is not a library. > > 4. You may copy and distribute the Library (or a portion or > derivative of it, under Section 2) in object code or executable form > under the terms of Sections 1 and 2 above provided that you accompany > it with the complete corresponding machine-readable source code, which > must be distributed under the terms of Sections 1 and 2 above on a > medium customarily used for software interchange. > > If distribution of object code is made by offering access to copy > from a designated place, then offering equivalent access to copy the > source code from the same place satisfies the requirement to > distribute the source code, even though third parties are not > compelled to copy the source along with the object code. > > 5. A program that contains no derivative of any portion of the > Library, but is designed to work with the Library by being compiled or > linked with it, is called a "work that uses the Library". Such a > work, in isolation, is not a derivative work of the Library, and > therefore falls outside the scope of this License. > > However, linking a "work that uses the Library" with the Library > creates an executable that is a derivative of the Library (because it > contains portions of the Library), rather than a "work that uses the > library". The executable is therefore covered by this License. > Section 6 states terms for distribution of such executables. > > When a "work that uses the Library" uses material from a header file > that is part of the Library, the object code for the work may be a > derivative work of the Library even though the source code is not. > Whether this is true is especially significant if the work can be > linked without the Library, or if the work is itself a library. The > threshold for this to be true is not precisely defined by law. > > If such an object file uses only numerical parameters, data > structure layouts and accessors, and small macros and small inline > functions (ten lines or less in length), then the use of the object > file is unrestricted, regardless of whether it is legally a derivative > work. (Executables containing this object code plus portions of the > Library will still fall under Section 6.) > > Otherwise, if the work is a derivative of the Library, you may > distribute the object code for the work under the terms of Section 6. > Any executables containing that work also fall under Section 6, > whether or not they are linked directly with the Library itself. > > 6. As an exception to the Sections above, you may also combine or > link a "work that uses the Library" with the Library to produce a > work containing portions of the Library, and distribute that work > under terms of your choice, provided that the terms permit > modification of the work for the customer's own use and reverse > engineering for debugging such modifications. > > You must give prominent notice with each copy of the work that the > Library is used in it and that the Library and its use are covered by > this License. You must supply a copy of this License. If the work > during execution displays copyright notices, you must include the > copyright notice for the Library among them, as well as a reference > directing the user to the copy of this License. Also, you must do one > of these things: > > a) Accompany the work with the complete corresponding > machine-readable source code for the Library including whatever > changes were used in the work (which must be distributed under > Sections 1 and 2 above); and, if the work is an executable linked > with the Library, with the complete machine-readable "work that > uses the Library", as object code and/or source code, so that the > user can modify the Library and then relink to produce a modified > executable containing the modified Library. (It is understood > that the user who changes the contents of definitions files in the > Library will not necessarily be able to recompile the application > to use the modified definitions.) > > b) Use a suitable shared library mechanism for linking with the > Library. A suitable mechanism is one that (1) uses at run time a > copy of the library already present on the user's computer system, > rather than copying library functions into the executable, and (2) > will operate properly with a modified version of the library, if > the user installs one, as long as the modified version is > interface-compatible with the version that the work was made with. > > c) Accompany the work with a written offer, valid for at > least three years, to give the same user the materials > specified in Subsection 6a, above, for a charge no more > than the cost of performing this distribution. > > d) If distribution of the work is made by offering access to copy > from a designated place, offer equivalent access to copy the above > specified materials from the same place. > > e) Verify that the user has already received a copy of these > materials or that you have already sent this user a copy. > > For an executable, the required form of the "work that uses the > Library" must include any data and utility programs needed for > reproducing the executable from it. However, as a special exception, > the materials to be distributed need not include anything that is > normally distributed (in either source or binary form) with the major > components (compiler, kernel, and so on) of the operating system on > which the executable runs, unless that component itself accompanies > the executable. > > It may happen that this requirement contradicts the license > restrictions of other proprietary libraries that do not normally > accompany the operating system. Such a contradiction means you cannot > use both them and the Library together in an executable that you > distribute. > > 7. You may place library facilities that are a work based on the > Library side-by-side in a single library together with other library > facilities not covered by this License, and distribute such a combined > library, provided that the separate distribution of the work based on > the Library and of the other library facilities is otherwise > permitted, and provided that you do these two things: > > a) Accompany the combined library with a copy of the same work > based on the Library, uncombined with any other library > facilities. This must be distributed under the terms of the > Sections above. > > b) Give prominent notice with the combined library of the fact > that part of it is a work based on the Library, and explaining > where to find the accompanying uncombined form of the same work. > > 8. You may not copy, modify, sublicense, link with, or distribute > the Library except as expressly provided under this License. Any > attempt otherwise to copy, modify, sublicense, link with, or > distribute the Library is void, and will automatically terminate your > rights under this License. However, parties who have received copies, > or rights, from you under this License will not have their licenses > terminated so long as such parties remain in full compliance. > > 9. You are not required to accept this License, since you have not > signed it. However, nothing else grants you permission to modify or > distribute the Library or its derivative works. These actions are > prohibited by law if you do not accept this License. Therefore, by > modifying or distributing the Library (or any work based on the > Library), you indicate your acceptance of this License to do so, and > all its terms and conditions for copying, distributing or modifying > the Library or works based on it. > > 10. Each time you redistribute the Library (or any work based on the > Library), the recipient automatically receives a license from the > original licensor to copy, distribute, link with or modify the Library > subject to these terms and conditions. You may not impose any further > restrictions on the recipients' exercise of the rights granted herein. > You are not responsible for enforcing compliance by third parties with > this License. > > 11. If, as a consequence of a court judgment or allegation of patent > infringement or for any other reason (not limited to patent issues), > conditions are imposed on you (whether by court order, agreement or > otherwise) that contradict the conditions of this License, they do not > excuse you from the conditions of this License. If you cannot > distribute so as to satisfy simultaneously your obligations under this > License and any other pertinent obligations, then as a consequence you > may not distribute the Library at all. For example, if a patent > license would not permit royalty-free redistribution of the Library by > all those who receive copies directly or indirectly through you, then > the only way you could satisfy both it and this License would be to > refrain entirely from distribution of the Library. > > If any portion of this section is held invalid or unenforceable under any > particular circumstance, the balance of the section is intended to apply, > and the section as a whole is intended to apply in other circumstances. > > It is not the purpose of this section to induce you to infringe any > patents or other property right claims or to contest validity of any > such claims; this section has the sole purpose of protecting the > integrity of the free software distribution system which is > implemented by public license practices. Many people have made > generous contributions to the wide range of software distributed > through that system in reliance on consistent application of that > system; it is up to the author/donor to decide if he or she is willing > to distribute software through any other system and a licensee cannot > impose that choice. > > This section is intended to make thoroughly clear what is believed to > be a consequence of the rest of this License. > > 12. If the distribution and/or use of the Library is restricted in > certain countries either by patents or by copyrighted interfaces, the > original copyright holder who places the Library under this License may add > an explicit geographical distribution limitation excluding those countries, > so that distribution is permitted only in or among countries not thus > excluded. In such case, this License incorporates the limitation as if > written in the body of this License. > > 13. The Free Software Foundation may publish revised and/or new > versions of the Lesser General Public License from time to time. > Such new versions will be similar in spirit to the present version, > but may differ in detail to address new problems or concerns. > > Each version is given a distinguishing version number. If the Library > specifies a version number of this License which applies to it and > "any later version", you have the option of following the terms and > conditions either of that version or of any later version published by > the Free Software Foundation. If the Library does not specify a > license version number, you may choose any version ever published by > the Free Software Foundation. > > 14. If you wish to incorporate parts of the Library into other free > programs whose distribution conditions are incompatible with these, > write to the author to ask for permission. For software which is > copyrighted by the Free Software Foundation, write to the Free > Software Foundation; we sometimes make exceptions for this. Our > decision will be guided by the two goals of preserving the free status > of all derivatives of our free software and of promoting the sharing > and reuse of software generally. > > NO WARRANTY > > 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO > WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. > EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR > OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY > KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE > IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE > LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME > THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. > > 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN > WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY > AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU > FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR > CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE > LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING > RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A > FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF > SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH > DAMAGES. > > END OF TERMS AND CONDITIONS > > How to Apply These Terms to Your New Libraries > > If you develop a new library, and you want it to be of the greatest > possible use to the public, we recommend making it free software that > everyone can redistribute and change. You can do so by permitting > redistribution under these terms (or, alternatively, under the terms of the > ordinary General Public License). > > To apply these terms, attach the following notices to the library. It is > safest to attach them to the start of each source file to most effectively > convey the exclusion of warranty; and each file should have at least the > "copyright" line and a pointer to where the full notice is found. > > > Copyright (C) > > This library is free software; you can redistribute it and/or > modify it under the terms of the GNU Lesser General Public > License as published by the Free Software Foundation; either > version 2.1 of the License, or (at your option) any later version. > > This library is distributed in the hope that it will be useful, > but WITHOUT ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > Lesser General Public License for more details. > > You should have received a copy of the GNU Lesser General Public > License along with this library; if not, write to the Free Software > Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > > Also add information on how to contact you by electronic and paper mail. > > You should also get your employer (if you work as a programmer) or your > school, if any, to sign a "copyright disclaimer" for the library, if > necessary. Here is a sample; alter the names: > > Yoyodyne, Inc., hereby disclaims all copyright interest in the > library `Frob' (a library for tweaking knobs) written by James Random Hacker. > > , 1 April 1990 > Ty Coon, President of Vice > > That's all there is to it! > ------------------------ end of proposed license ------------------ > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From gjhanna at gmail.com Sun Mar 11 14:21:17 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Mon, 12 Mar 2007 09:21:17 +1300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hi Pavel, We are using RXTX under VMWare server in production, quite satisfactorily. We're using Red Hat Enterprise Server 4, and ... Whatever the "enterprise" VMWare product is. Regards, Greg H > Subject: [Rxtx] RXTX under VMWare server > To: rxtx at qbang.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. [ ... snip ... ] -- Pavel Parkhomenko -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070311/4cebb6f9/attachment-0003.html From gergg at cox.net Sun Mar 11 23:39:19 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 12 Mar 2007 00:39:19 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: <45F4E787.6050502@cox.net> Trent Jarvi wrote: > I can start going through the method interfaces later this week and giving > feedback. I would suggest that the JSR should not be too generic in > nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel > drivers that intend to look like EIA232 ports at the kernel driver level. > > some ideas: > > EIA232PortInterface > TermiosInterface > SerialPortInterface > > Something that differentiates this from thing like USB, I2C, ... which > should not have to deal with legacy serial claiming to be the comm api. I'm going to throw out a suggestion, which I am mostly serious about. What would happen if we took the appropriate bits of the J2ME connector API, and just used that as the new COMM API so that finally JSE and JME had a common foundation for these kinds of things? Gregg Wonderly From ra85551 at gmail.com Mon Mar 12 09:08:37 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Mon, 12 Mar 2007 18:08:37 +0300 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Should any application use the modem, HyperTerminal won't be able to talk to the modem. But it actually can send and receive AT comands, while my application cannot :-( > Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Thansk for the reference. I examined that example and found that there's no significant differences between my read/write implementation and that one, except that SimpleSnuV1 listens for serialEvent's, but not for sake of data retrieval, just for printing them out - I don't know why ;-) > Note that modems could care less what OS is on top. If you are trying to > match new lines to the OS and sending it to the mode for AT commands, > thats probably a mistake. I do send strings to serial port, not to OS, and do try to get answers back. If it is the mistake, what's the right way? > Also it would not hurt to print out the > individual bytes that you are sending to make sure they did not get > mangled along the path. Yeah, I am printing these bytes before doing write, but it means that I only see what I intend to write. How can I ensure that these bytes have gone out of the box and reached my modem? BTW, I found that my send/receive method is complex enough, so I've rewritten it. Please, see the following code and point any mistakes, because I don't know where can they remain yet. private static final int LARGE_TIMEOUT = 15000; private static final int SMALL_TIMEOUT = 500; ... private String sendATCommand(String command, String waitFor, boolean isRegex, boolean isAddCRLF) throws BeaconConnectException { byte[] buffer = new byte[512]; int offset; String result = ""; try { if (waitFor != null) { serialPort.enableReceiveTimeout(LARGE_TIMEOUT); } else { serialPort.enableReceiveTimeout(SMALL_TIMEOUT); } if (command != null) { OutputStream serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } offset = 0; InputStream serialInput = serialPort.getInputStream(); while (serialInput.available() != -1) { int bytesRead = serialInput.read(buffer, offset, buffer.length - offset); if (bytesRead == 0) { break; } offset += bytesRead; result = new String(buffer, 0, offset).trim(); if (waitFor != null) { System.out.println(result); if (isRegex && result.matches(waitFor) || result.contains(waitFor)) { break; } } } } catch (UnsupportedCommOperationException e) { throw new MyException("unsupported operation"); } catch (IOException e) { throw new MytException("serial I/O error"); } return result; } -- Pavel Parkhomenko From clayno at hotpop.com Thu Mar 15 02:47:34 2007 From: clayno at hotpop.com (Christopher Layno) Date: Thu, 15 Mar 2007 16:47:34 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi, we're using the latest release of rxtx (2.1-7r2) for our system that has two applications using the library. one application sends requests to the modem while the other simply checks the modem status. we deployed our system on a pentium machine with red hat linux 9.0 installed. now the problem arises when these two applications try to access the same modem at the same time. one of them will eventually have to throw the PortInUseException as shown below: 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException gnu.io.PortInUseException: root PID = 743 Program = java root PID = 743 Program = java root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) this was expected. what we didn't expect though was that if we repeat the scenario 5 times, always 5 times, the application would also throw a VM error: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4473CD21 Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so Current Java thread: at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) - locked <0x44cfd4c8> (a gnu.io.CommPortIdentifier) at ************ at ************ - locked <0x4476a468> (a **********) at ************ at ************ at ************ at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java :261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages( TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run( TCPTransport.java:701) at java.lang.Thread.run(Thread.java:534) note: i replaced some sensitive data with asterisks our team has looked everywhere on the internet, including your mail archives, for a solution to this problem but to no avail. i really hope you could help us out on this one. thanks in advance! best regards, chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070315/1936460a/attachment-0003.html From tjarvi at qbang.org Fri Mar 16 04:30:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 04:30:25 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: On Thu, 15 Mar 2007, Christopher Layno wrote: > hi, > > we're using the latest release of rxtx (2.1-7r2) for our system that has two > applications using the library. one application sends requests to the modem > while the other simply checks the modem status. we deployed our system on a > pentium machine with red hat linux 9.0 installed. > > now the problem arises when these two applications try to access the same > modem at the same time. one of them will eventually have to throw the > PortInUseException as shown below: > > 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException > gnu.io.PortInUseException: root PID = 743 Program = java root PID = > 743 Program = java root PID = 743 Program = ??? root PID = 743 Program > = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root > PID = 743 Program = ??? root PID = 743 Program = ??? > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > > this was expected. what we didn't expect though was that if we repeat the > scenario 5 times, always 5 times, the application would also throw a VM > error: > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x4473CD21 > Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 > Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so > > Current Java thread: > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) Hi Chris The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. The code is originally by Werner Almesberger. He gave us permission to use it in rxtx. You might look at what has changed since 1998 in his fuser application. Or you can just do like other OSs and do the following in fuserImp.c JNIEXPORT jstring JNICALL Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv *env, jobject obj, jstring arg) { return (*env)->NewStringUTF(env, "Unknown Application"); } It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. -- Trent Jarvi tjarvi at qang.org From Adrien.TOS at ingenico.com Fri Mar 16 05:11:12 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Fri, 16 Mar 2007 12:11:12 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903CBC312@frsnprexc1.usr.ingenico.loc> Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070316/972ab214/attachment-0003.html From joachim at buechse.de Fri Mar 16 05:13:24 2007 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 16 Mar 2007 12:13:24 +0100 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. From tjarvi at qbang.org Fri Mar 16 16:36:29 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 16:36:29 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Fri Mar 16 16:02:23 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 16 Mar 2007 18:02:23 -0400 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Not all platforms are Unix based. Also mixing native library usage and command-line calls is not an elegant solution, IMHO. One or the other, but not both. Andre On 16-Mar-07, at 07:13 , Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is > trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We >> only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From clayno at hotpop.com Sun Mar 18 22:17:28 2007 From: clayno at hotpop.com (Christopher Layno) Date: Mon, 19 Mar 2007 12:17:28 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi everyone, thank you so much for your replies. they were really helpful. anyway, before i sent the email, my team was already implementing a temporary solution by using joachim's suggestion. we invoked a lsof command from our java code although i share the same concern with trent and andre-john about portability issues. that's why i said it's just temporary. my superiors have yet to approve our bug fix. so my question now is this: is recompiling the rxtx source code the only way to solve this problem? because if it's the only solution, then i think my superiors would rather have a new release from the rxtx community itself that fixes this bug(?) rather than have my team recompile the source code. best regards, chris Trent Jarvi wrote: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. ... It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070318/237463b2/attachment-0003.html From tjarvi at qbang.org Mon Mar 19 16:20:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Mar 2007 16:20:52 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: Hi Chris I can compile a new version after the 21st if you do not feel comfortable doing so. Please send me an email reminder off-line then. On Mon, 19 Mar 2007, Christopher Layno wrote: > hi everyone, > > thank you so much for your replies. they were really helpful. > > anyway, before i sent the email, my team was already implementing a > temporary solution by using joachim's suggestion. > we invoked a lsof command from our java code although i share the same > concern with trent and andre-john about > portability issues. that's why i said it's just temporary. my superiors have > yet to approve our bug fix. > > so my question now is this: is recompiling the rxtx source code the only way > to solve this problem? because if it's the only > solution, then i think my superiors would rather have a new release from the > rxtx community itself that fixes this bug(?) > rather than have my team recompile the source code. > > best regards, > > chris > > Trent Jarvi wrote: > > Hi Joachim > > It would be nice to have that functionality but calling the program > introduces too many issues imho. Explaining to someone why rxtx invoked a > rogue lsof does not sound very interesting. > > On Fri, 16 Mar 2007, Joachim Buechse wrote: > > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: > > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. > > _______________________________________________ > Rxtx mailing list > Rxtx 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 Eric.Arseneau at sun.com Tue Mar 20 11:47:33 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Tue, 20 Mar 2007 10:47:33 -0700 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 Message-ID: <46001E35.9040608@sun.com> Anyone have any experience with RXTX working with JDK 6 on other platforms ? From mm at UDel.Edu Tue Mar 20 12:18:29 2007 From: mm at UDel.Edu (Mike Markowski) Date: Tue, 20 Mar 2007 14:18:29 -0400 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 In-Reply-To: <46001E35.9040608@sun.com> References: <46001E35.9040608@sun.com> Message-ID: <46002575.4000306@udel.edu> Eric Arseneau wrote: > Anyone have any experience with RXTX working with JDK 6 on other platforms ? I'm using 32 bit intel, gentoo linux, jdk6 with no problems. My applications only use a serial port, though, nothing on the parallel port. Mike From falko.guderian at gmx.de Wed Mar 21 08:17:35 2007 From: falko.guderian at gmx.de (Falko Guderian) Date: Wed, 21 Mar 2007 15:17:35 +0100 Subject: [Rxtx] RXTX binaries for SH4 Message-ID: <46013E7F.40102@gmx.de> Dear developers, I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no possiblities to compile the source code. Better, I'm not able to do this at the moment. Can you provide me with rxtxSerial.dll (SH4) in the rxtx-2.1-8-testing version? (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) The reason for the testing version is I need custom baud rates. Thanks for help. Kind regards, Falko Guderian From tjarvi at qbang.org Wed Mar 21 21:38:37 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Mar 2007 21:38:37 -0600 (MDT) Subject: [Rxtx] RXTX binaries for SH4 In-Reply-To: <46013E7F.40102@gmx.de> References: <46013E7F.40102@gmx.de> Message-ID: On Wed, 21 Mar 2007, Falko Guderian wrote: > Dear developers, > > I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no > possiblities to compile the source code. Better, I'm not able to do this > at the moment. Can you provide me with rxtxSerial.dll (SH4) in the > rxtx-2.1-8-testing version? > (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) > > The reason for the testing version is I need custom baud rates. > > Thanks for help. > Hi Falko WinCE binary format is not supported by gcc. That makes compiling limited to those familiar with the WinCE tools. I hope someone is able to provide them for you but it is not likely. WinCE has been compiled by others in the past but rxtx.org builds have never included WinCE. There is some information with the source concerning WinCE builds if you decide to do it. We can share your results too if you like. The source in the WinCE has never been updated for the custom baud rate. That would need changes from the main source I presume. If you look at the source, you will note that Michal Hobot created a mini fork in the source to handle wince but it has not been updated for 3 years. -- Trent Jarvi tjarvi at qbang.org From Adrien.TOS at ingenico.com Thu Mar 22 07:08:55 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Thu, 22 Mar 2007 14:08:55 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Hi everybody, Do you have any comments on this issue? Thanks! AT ________________________________ De : Adrien TOS Envoy? : vendredi 16 mars 2007 12:11 ? : 'rxtx at qbang.org' Cc : Adrien TOS Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070322/2306c538/attachment-0003.html From jeremy.reeve at zen.co.uk Mon Mar 19 07:36:04 2007 From: jeremy.reeve at zen.co.uk (Jeremy S. Reeve) Date: Mon, 19 Mar 2007 13:36:04 +0000 Subject: [Rxtx] rxtx failing to compile on Fedora Core 6 Message-ID: <1174311364.21865.6.camel@d9thc> When trying to compile latest source : rxtx-2.1-7r2 I get the following when running configure: ---------------- checking os.version 2.6.18-1.2200.fc5smp WARNING: configure is having a hard time determining which directory contains the file jni_md.h. Edit Makefile and fix the variable JAVANATINC to point to the correct directory. The following options are available: /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/ /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/linux/ If there are more than one option available the first was selected. WARNING: Kernel include files do not match the current kernel configure: creating ./config.status ------------------------ which seems OK checking the resultant Makefile but when attempting to build with gmake install I get the following output : ---------------------- 34 problems (34 warnings)/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/javah -classpath .:/home/jsr/rxtxsrc/rxtx-2.1-7r2:/home/jsr/rxtxsrc/rxtx-2.1-7r2/src:/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/ext/RXTXcomm.jar -d i686-pc-linux-gnu -jni `(for i in CommDriver CommPortEnumerator CommPortIdentifier CommPort CommPortOwnershipListener Configure I2C I2CPortEvent I2CPortEventListener I2CPort LPRPort NoSuchPortException ParallelPortEvent ParallelPortEventListener ParallelPort PortInUseException Raw RawPortEvent RawPortEventListener RawPort RS485 RS485PortEvent RS485PortEventListener RS485Port RXTXCommDriver RXTXPort RXTXVersion SerialPortEvent SerialPortEventListener SerialPort UnsupportedCommOperationException UnSupportedLoggerException Zystem;do \ if grep > /dev/null native.* \( /home/jsr/rxtxsrc/rxtx-2.1-7r2/./src/$i.java; then \ echo gnu.io.$i; \ fi; \ done)` i686-pc-linux-gnu/gnu_io_CommPortIdentifier.h: No such file or directory make: *** [/home/jsr/rxtxsrc/rxtx-2.1-7r2/gnu/io/CommDriver.class] Error 1 ------------------------ Any ideas or pointers? Regards, Jeremy From tjarvi at qbang.org Sat Mar 24 08:12:54 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 Mar 2007 08:12:54 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > From Adrien.TOS at ingenico.com Sat Mar 24 11:53:22 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Sat, 24 Mar 2007 18:53:22 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> I do not have the threshold setting enabled, I have explicitely disabled it with: port_.disableReceiveThreshold(); I have also run the same tests with the threshold setting enabled, but they also fail in the same way as described below. So it seems there is a problem with timeout handling on Win32? ________________________________ From: rxtx-bounces at qbang.org on behalf of Trent Jarvi Sent: Sat 3/24/2007 3:12 PM To: RXTX Developers and Users Subject: Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 8312 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20070324/f9e39c9b/attachment-0003.bin From greg.johnson at manchester.ac.uk Sun Mar 25 13:41:36 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Sun, 25 Mar 2007 21:41:36 +0200 Subject: [Rxtx] Mac intel weirdness Message-ID: Hi folks, I'm trying to get rxtx to work on my macbook pro with a USB-serial dongle on it. I am using the 2.1-8 code from the CVS (though it seems to report itself as 2.1-7: makes it difficult to prove to oneself that the changes have 'taken'! - line 4210 in SerialImp.c, line 40 in RXTXVersion.java) I am trying the 2.1-8 because of horrible lock problems in 2.1-7. However, the serialport closure code seems to be broken - it won't close because it believes the (previously opened!) port doesn't exist. Here is what I'm trying: 0. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "false" 1. Open a port Serialport serialport = (SerialPort) commportidentifier.open ("test",100); 2. Talk to a device ... 3. Close port serialport.close(); 4. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "true" - why is this? 5. Try to reopen port Serialport serialport2 = (SerialPort) commportidentifier.open("test", 100); throws PortInUseException. I've dug around a bit in the source, and it seems the SerialPort.close () should call the CommPortIdentifier.internalClosePort() (line 67 of CommPort.java). However, I crash out with the NoSuchPortException when getPortIdentifier is called. Which seems quite weird to me, seeing as it is called on this - which was create just beforehand. Does anyone know how to fix this? Cheers, greg From knute at frazmtn.com Sat Mar 24 10:32:38 2007 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 24 Mar 2007 09:32:38 -0700 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc>, Message-ID: <4604F036.17833.135298@knute.frazmtn.com> > >The behavior of timeout depends upon the setting of the threshold. Do you >have the threshold setting? > This is the same bug I reported last fall. There was a fellow that sent me an email asking if it had been fixed. I told him I didn't think so. He got somebody to write a fix for him but I have not been able to contact him again for the actual changes. The inaccurate timeout and the failure of blocking when no timeouts are set is a serious bug in my humble opinion and renders the software unusable for my applications. I'd really like to have an alternative to the Sun comm api but there just isn't one that I know of. -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Mar 26 16:17:00 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 26 Mar 2007 16:17:00 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> Message-ID: >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. From ra85551 at gmail.com Tue Mar 27 10:18:36 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Tue, 27 Mar 2007 20:18:36 +0400 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Ultimately I found a solution. At first, that wasn't actually the VMWare + WinXP + RXTX issue, that was WinXP + RXTX issue. But on pure XP it sometimes workes, sometimes not, while under VMWare I had never seen my snippet working at all. SimpleSnuV1.java would not help me, because there is only one line I missed, and SimpleSnuV1.java also doesn't contain it! It is as follows: serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_OUT | SerialPort.FLOWCONTROL_RTSCTS_IN); Thank you for your attention. -- Pavel Parkhomenko From griff at op.pl Wed Mar 28 01:28:19 2007 From: griff at op.pl (griff@op.pl) Date: Wed, 28 Mar 2007 09:28:19 +0200 Subject: [Rxtx] No blocking read on Windows. Message-ID: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/5d07d571/attachment-0003.html -------------- next part -------------- Hi, I have problem that InputStram.read() (SerialPort)?returns -1 instead blocking and waiting for data. I found that this problem was ?known in 2005 : ? >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > >> Hi Trent >> >> Thanks for the fast response. >> Here's a Q&D test program for the blocking read on windows that just >> attempts to read one byte, and prints the resulting byte. On my system it >> returns -1, where I expect that it keeps waiting for data. >> >This isn't happening on Linux so the bug is in src/termios.c.? I'll have >something this weekend to fix that. I'm using RXTX 2.1.7r2 and the problem still is here. Im using Windows XP and java 1.5 disableReciveTimeout() and disableReciveTreshhold() dont help. ? best regards ? Piotr Zielniok From Adrien.TOS at ingenico.com Wed Mar 28 01:40:46 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Wed, 28 Mar 2007 09:40:46 +0200 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903E88880@frsnprexc1.usr.ingenico.loc> Looking at the code, it seems there is no support for infinite timeout? And maybe the count++ < 20 condition is breaking out of the loop too early? The only condition to break out of the loop should either be the timeout has expired or the number of requested bytes has been received. -----Message d'origine----- De : rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] De la part de Trent Jarvi Envoy? : mardi 27 mars 2007 00:17 ? : RXTX Developers and Users Objet : Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From j.kenneth.gentle at acm.org Wed Mar 28 06:44:15 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 28 Mar 2007 08:44:15 -0400 Subject: [Rxtx] No blocking read on Windows. In-Reply-To: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> References: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> Message-ID: <200703281844.l2SIiITW028614@qbang.org> Just another "ME TOO!" - I'm seeing this problem on Windows XP, jre for windows XP/Embedded. I cranked receiveTimeout up to Integer.MAX_INT, but it doesn't seem to wait that long At 03:28 2007-03-28, you wrote: >Hi, >I have problem that InputStram.read() (SerialPort) returns -1 >instead blocking and waiting for data. I found that this problem >was known in 2005 : > > >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > > > >> Hi Trent > >> > >> Thanks for the fast response. > >> Here's a Q&D test program for the blocking read on windows that just > >> attempts to read one byte, and prints the resulting byte. On my system it > >> returns -1, where I expect that it keeps waiting for data. > >> > > >This isn't happening on Linux so the bug is in src/termios.c. I'll have > >something this weekend to fix that. > >I'm using RXTX 2.1.7r2 and the problem still is here. >Im using Windows XP and java 1.5 >disableReciveTimeout() and disableReciveTreshhold() dont help. > >best regards > >Piotr Zielniok > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From greg.johnson at manchester.ac.uk Wed Mar 28 14:43:29 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Wed, 28 Mar 2007 22:43:29 +0200 Subject: [Rxtx] Cannot close and reopen serial port Message-ID: <377F9765-7A9D-4CE9-9176-FFB63A2594F0@manchester.ac.uk> Dear all, It appears I cannot close a port properly: SerialPort serialport = portid.open("myprog",100); // do some stuff, all works fine serialport.close(); // all seems fine but... SerialPort sp2 = portid.open("myprog",100); throws PortInUseException. And when I dig into the rxtx code, I find in CommPort.java, in close(): CommPortIdentifier cp = CommPortIdentifier.getPortIdentifier(this); (line 64 or there abouts) but this throws a NoSuchPortException which is caught but ignored (line 74ish). Can anyone suggest how this could happen: a port that was valid, opened, and used, throws a NSPE when it comes to closing it? I'm pulling my (remaining) hair out over this one! Cheers, greg PS And thanks for RXTX - it's great to have! PPS (21.-7. winxp/osx both, java 1.5) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/c28852fc/attachment-0003.html From rxtx at vrijheidslaan.net Fri Mar 30 16:52:50 2007 From: rxtx at vrijheidslaan.net (Rob) Date: Fri, 30 Mar 2007 22:52:50 -0000 Subject: [Rxtx] Cvs Question Message-ID: <61896.80.126.150.87.1175295162.squirrel@webmail.provalue.nl> Hi There, Im trying to get the latest version to work on mac osx. Problem is that i can't checkout version 2.1.8. Probably my fault but can some one please give me the alternative commands for: [user at myhost]$ export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot [user at myhost]$ cvs login Thanx, Rob From ra85551 at gmail.com Thu Mar 1 03:47:06 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Thu, 1 Mar 2007 13:47:06 +0300 Subject: [Rxtx] enableReceiveTimeout() issue Message-ID: Hello, world! I found a limitation of 16300 ms for CommPort's enableReceiveTimeout() method, while in original javax.comm docs there are no any references to that. Is that a bug or feature? I actually need longer timeouts sometimees. -- Pavel Parkhomenko From lyon at docjava.com Thu Mar 1 07:54:17 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 01 Mar 2007 09:54:17 -0500 Subject: [Rxtx] parametric singleton design pattern In-Reply-To: References: <22d55aea0702081207q5e7f6785l352d498d6f5f9fb1@mail.gmail.com> <22d55aea0702100034o3bcf42f3j1d1a6257029a67b0@mail.gmail.com> Message-ID: Hi All, I have been thinking about the use of a design pattern to cache resources that are consumed by processes. Toward that end, I have arrived at a parametric singleton design pattern, which I mentioned on this list some time ago. The idea has been published at: http://www.jot.fm/issues/issue_2007_03/column2 I can't help but think that there should be an API available for dealing with the tracking of serial port usage. Perhaps it is a kind of resource manager called the: SerialPortManager basic prototypes already exist in this vain. See, for example: http://www.ce.rit.edu/research/projects/2005_fall/rt_poolsystem/doc/PoolMon/SerialPortManager.html http://www.eventhelix.com/RealtimeMantra/PatternCatalog/serial_port_design_pattern.htm And others shown by a google search on "SerialPortManager" Cheers! - Doug From Eric.Arseneau at sun.com Thu Mar 1 10:15:03 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:15:03 -0800 Subject: [Rxtx] Any known Java 6 issues with RXTX 2.1-7r2 ? Message-ID: <45E70A17.1060206@sun.com> I just did a test on a recent build of Solaris 11 x86 and it seems that I can connect to my serial device fine when Java 5 is the default, but when Java 6 is the default, no go. Any information ? From Eric.Arseneau at sun.com Thu Mar 1 10:19:58 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:19:58 -0800 Subject: [Rxtx] Mac OS X and missing data Message-ID: <45E70B3E.7040908@sun.com> We have a device which is USB based but presents itself as a serial port to a machine. On my MacBook Pro I can get excellent throughput if I get my device to send data as quickly as possible. On the desktop side, if I do an type of disk IO to log the data I get, I end up with some missing data at some point. I hooked up a USB analyzer and did confirm that all the data is sent as expected to the desktop from the device. I found a work around for this, buffer the data in memory and only write the data out when I've received it all. However, when the same code and same device is attempted on a co-workers MacBook Pro (same hardware specs), I get errors and must slow down dramatically the device side's sending of data. Any ideas/recommendations on what I can do to get rid of this error ? From what I can tell, it seems that RXTX is not able to wake up to the interrupts coming in indicating data is ready, quickly enough, is there anything I can do ? From chinkaiw at hotmail.com Fri Mar 2 00:57:43 2007 From: chinkaiw at hotmail.com (Wang Chinkai) Date: Fri, 02 Mar 2007 07:57:43 +0000 Subject: [Rxtx] dynamic detect rs232 port Message-ID: Hi all I have a question about detecting rs232 port dynamicly. I have to aceess some port and detect rs232 port at the same time. Some usb device simulates rs232 port , and I can not know what the port name it gets until it connects,so I have to detect it dynamic,but I have to access another rs232 device at the same time. I found a problem. If I use CommPortIdentifier.getPortIdentifiers() to get new port list , and the other rs232 access function will not close port correctly. So , How can I solve it . Thanks. _________________________________________________________________ ?? 2GB ???? Windows Live Mail ????????????? http://ideas.live.com/programpage.aspx?versionid=5d21c51a-b161-4314-9b0e-4911fb2b2e6d From eu259473 at tele2.it Fri Mar 2 06:16:40 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 02 Mar 2007 14:16:40 +0100 Subject: [Rxtx] rxtx on HP tru 64 unix Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070302/706c7a70/attachment-0004.html From tjarvi at qbang.org Fri Mar 2 08:39:33 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 08:39:33 -0700 (MST) Subject: [Rxtx] rxtx on HP tru 64 unix In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, "Giuseppe Marchese" wrote: > Hi > > I try to install rxtx on hp tru 64 but make fails, > There are somebody that do the same and work. > > > Sorry for may english! > > Hi Giuseppe Could you provide a log of the failure? script ./configure make # use gnu make exit The information will be in the typescript created. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 2 19:56:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 19:56:52 -0700 (MST) Subject: [Rxtx] dynamic detect rs232 port In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, Wang Chinkai wrote: > Hi all > > I have a question about detecting rs232 port dynamicly. > > I have to aceess some port and detect rs232 port at the same time. > Some usb device simulates rs232 port , and I can not know > what the port name it gets until it connects,so I have to detect it > dynamic,but I have to access > another rs232 device at the same time. > > I found a problem. Hi Wang This is a known problem. The code is braindead there. In fact there needs to be events even in a rudamentary way when you add a usb dongle. I'm burried in tasks not far from rxtx but not in rxtx. I can't get to the problem but we would accept patches if you dig into it. [I'm getting to the license question earlier too; I don't have another 10%] -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Fri Mar 2 23:19:01 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 01:19:01 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Hi, Under ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable USB -> serial converter(using virtual com port drivers), with using example code pretty much straight out of http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port opens fine, enumerations all work, etc. My application calls for a large amount of data to be transferred in a short amount of time at 2,000,000 baud. My hardware sends approximately 15,232 bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL converter work fine, and the application works using C++. In C++, I do a hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); to open the port, and a boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); to read the port. The variable buffer fills with the 15238 bytes, and returns. If I do a resultz = is.read(cbuf,0,15238); in java with RXTX where is = new BufferedReader(new InputStreamReader(port.getInputStream())); and where resultz is an int, and cbuf is a char [] cbuf, resultz gets EXACTLY 3968 bytes the first time called. If I call it multiple times, I get roughly 11k total(less than what is sent), never more than the 3968 bytes per is.read() call. My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 bytes. I've played with inputbuffersize, receive threshold, receivetimeout, and so on. The FTDI virtual com port drivers that I'm using are rock solid, and have had zero problems with them using a variety of applications, some of my own, some professionally written, etc. No flow control is used anyplace, no RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. No exceptions are being thrown. What am I doing wrong, and what I can adjust to receive the full 15k bytes in one single read? Thanks! Keith From Eric.Arseneau at sun.com Fri Mar 2 23:32:07 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Fri, 02 Mar 2007 22:32:07 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <45E91667.20501@sun.com> This is the same type of thing that is happening to me on Mac OS X and does not seem to behave the same on different machines. I posted a day or two ago on this with subject "Mac OS X and missing data". Would love to hear if there is a solution to this :) From tjarvi at qbang.org Sat Mar 3 10:54:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 10:54:17 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > Hi, > > Under > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable > USB -> serial converter(using virtual com port drivers), with using example > code pretty much straight out of > http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port > opens fine, enumerations all work, etc. > > My application calls for a large amount of data to be transferred in a short > amount of time at 2,000,000 baud. My hardware sends approximately 15,232 > bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL > converter work fine, and the application works using C++. > > In C++, I do a > > hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, > OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); > > to open the port, and a > > boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); > > to read the port. > > The variable buffer fills with the 15238 bytes, and returns. > > If I do a > > resultz = is.read(cbuf,0,15238); in java with RXTX > > where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > > and where resultz is an int, and cbuf is a char [] cbuf, resultz gets > EXACTLY 3968 bytes the first time called. If I call it multiple times, I get > roughly 11k total(less than what is sent), never more than the 3968 bytes > per is.read() call. > > My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 > bytes. > > I've played with inputbuffersize, receive threshold, receivetimeout, and so > on. The FTDI virtual com port drivers that I'm using are rock solid, and > have had zero problems with them using a variety of applications, some of my > own, some professionally written, etc. No flow control is used anyplace, no > RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. > > No exceptions are being thrown. > > What am I doing wrong, and what I can adjust to receive the full 15k bytes > in one single read? > > Thanks! > Hi Keith I would expect a 20 meg application is going to have different behavior with the OS than a smaller application with respect to the kernel memory managment, schedualing, ... Something subtle could be causing problems. With respect to the recieve timeout and threshold, if you set the timeout to zero and the threshold to the size of data you expect, read should not return until it get that data. You may try with a stand alone application that tests just that with the C/C++ API. If the read is returning with less data when tested for short reads, you have found a bug in the device driver more than likely. The USB dongle vendor would probably be interested in knowing about this. As mentioned, these devices are getting very good; almost bug free. I suspect you found a bug though if you did use the threshold and timeout properly. The missing data is typical when not using flow control. When the OS buffering fills, the hardware will start dropping bytes. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:38:52 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:38:52 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> update: I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now instead of 3968. This makes sense. 128 bytes of overhead + 3968 bytes of data = 4096 transfer size 32 bytes of overhead + 992 bytes of data = 1024 transfer size. 1/4 the data = 1/4 the overhead. I rearranged my reading like so: resultz = is.read(cbuf,0,3968); resultz = is.read(cbuf,3968,3968); resultz = is.read(cbuf,7936,3968); while (!(is.ready())); // wait for ready resultz = is.read(cbuf,11904,3334); and this grabs 15,238 bytes total. BUT, I still have the quandry of the screwed up multi-bytes. I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. Approx 8% of the data. The bad bytes always seem to take the flavor of 0x2018, 0x2019, x2022, x2030, x201d. Are these maybe errors and I don't know what they enumerate to? I still can't believe some other layer isn't handling putting those bytes together all in one stream for me. Thanks Keith ----- Original Message ----- From: "Keith" To: "Bob Jacobsen" ; "RXTX Developers and Users" Sent: Saturday, March 03, 2007 11:26 AM Subject: Re: [Rxtx] is.read() only returning 3968 bytes > Bob, > > > Interesting numerical coincidence is that (max USB transfer) - (what > > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > > needed to transfer that much data. > > I was thinking along the same lines. I don't know USB well, but I do know > that those numbers were close enough to warrant investigating the > relationship between them. > > > I think what you're seeing is the internal buffering of the USB data > > stream. You'll need some form of higher-level buffering to smooth > > that out. > > Shouldn't the InputStreamReader() and BufferedReader() provide this type of > buffering? Isn't that the idea behind those? > > > All hypotheses need to be tested. In this case, a test would be to > > check for missing data. If this idea is right, you'll get _all_ the > > data, but you won't be missing characters. > > I did start looking at the data. -- I'm getting weird results. > > I tried this: > > loopzz = 0; > > for (looptwo = 0; looptwo < 100000; looptwo++) { > while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > > }} > > So I'm reading one character at a time. The good news is that loopzz is > exactly 15238 at the end of the routine, which is perfectly correct. I > picked looptwo value out of thin air. > > The weird results come in terms of the values, the data isn't correct at > least in one case. Look here: > > 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > > This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). > But the 0x89 was replaced by 0x2030. Why the heck would the returned value > be 0x2030?? Why is the returned byte completely out of range? Why the > multibyte return? > > From InputStream in the API: > > read > public abstract int read() > throws IOExceptionReads the next byte of data from the > input stream. The value byte is returned as an int in the range 0 to 255. If > no byte is available because the end of the stream has been reached, the > value -1 is returned. This method blocks until input data is available, the > end of the stream is detected, or an exception is thrown. > Value should be 0-255. > > > In my application time is really critical, reading 1 byte at a time is > probably not going to work. > > Thanks Eric & Bob for looking at this. > > Keith > From tjarvi at qbang.org Sat Mar 3 12:52:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 12:52:27 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > update: > > I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now > instead of 3968. > > This makes sense. > > 128 bytes of overhead + 3968 bytes of data = 4096 transfer size > 32 bytes of overhead + 992 bytes of data = 1024 transfer size. > > 1/4 the data = 1/4 the overhead. > > I rearranged my reading like so: > > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. > Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? > > I still can't believe some other layer isn't handling putting those bytes > together all in one stream for me. > The layer for this in Serial land is flow control. Software and hardware flow control prevent the overruns you observe. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:54:41 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:54:41 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <001a01c75dcd$c8802a70$6600a8c0@jbh757ktruws7g> Trent, Thanks for taking the time to reply. > I would expect a 20 meg application is going to have different behavior > with the OS than a smaller application with respect to the kernel memory > managment, schedualing, ... Something subtle could be causing problems. Well, at least I know the VCP drivers, the OS, etc can handle 2mbps reliably. Without hiccuping or dropping bytes. The C++ code works reliably without flow control. > The missing data is typical when not using flow control. When the OS > buffering fills, the hardware will start dropping bytes. I'm actually not getting MISSING data, I'm getting CORRUPTED data. If you look at my most recent post, I'm getting these bad bytes in place of the correct values: 0x2018, 0x2019, x2022, x2030, x201d. Why would is.read() return values not in the range of 0-255 ? Thanks. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 08:59:14 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 07:59:14 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: At 1:19 AM -0500 3/3/07, Keith wrote: >If I do a > >resultz = is.read(cbuf,0,15238); in java with RXTX > >where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > >and where resultz is an int, and cbuf is a char [] cbuf, resultz gets >EXACTLY 3968 bytes the first time called. If I call it multiple times, I get >roughly 11k total(less than what is sent), never more than the 3968 bytes >per is.read() call. > >My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 >bytes. Interesting numerical coincidence is that (max USB transfer) - (what you get) = 4096-3968 = 128 bytes is (almost) the size of the headers needed to transfer that much data. I think what you're seeing is the internal buffering of the USB data stream. You'll need some form of higher-level buffering to smooth that out. All hypotheses need to be tested. In this case, a test would be to check for missing data. If this idea is right, you'll get _all_ the data, but you won't be missing characters. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 09:26:14 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 11:26:14 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Bob, > Interesting numerical coincidence is that (max USB transfer) - (what > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > needed to transfer that much data. I was thinking along the same lines. I don't know USB well, but I do know that those numbers were close enough to warrant investigating the relationship between them. > I think what you're seeing is the internal buffering of the USB data > stream. You'll need some form of higher-level buffering to smooth > that out. Shouldn't the InputStreamReader() and BufferedReader() provide this type of buffering? Isn't that the idea behind those? > All hypotheses need to be tested. In this case, a test would be to > check for missing data. If this idea is right, you'll get _all_ the > data, but you won't be missing characters. I did start looking at the data. -- I'm getting weird results. I tried this: loopzz = 0; for (looptwo = 0; looptwo < 100000; looptwo++) { while (is.ready()) { cbuf[loopzz] = (char) is.read(); loopzz++; }} So I'm reading one character at a time. The good news is that loopzz is exactly 15238 at the end of the routine, which is perfectly correct. I picked looptwo value out of thin air. The weird results come in terms of the values, the data isn't correct at least in one case. Look here: 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). But the 0x89 was replaced by 0x2030. Why the heck would the returned value be 0x2030?? Why is the returned byte completely out of range? Why the multibyte return? >From InputStream in the API: read public abstract int read() throws IOExceptionReads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown. Value should be 0-255. In my application time is really critical, reading 1 byte at a time is probably not going to work. Thanks Eric & Bob for looking at this. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 14:44:50 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 13:44:50 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: Java's "char" type is Unicode. I think what you're seeing is a bug in the byte -> Unicode translation. 0x2018, 0x2019 are the curly open and close quotes. There used to be (and might still be) bugs in the conversion of these in a couple of libc versions. Some of the ASCII -> ISO and ISO -> ASCII routines were a little over-ambitious with respect to handling the open and close quotes, and tried to convert them to the "curly" form inappropriately. Try _not_ casting it to char. Bob At 11:26 AM -0500 3/3/07, Keith wrote: >Bob, > >> Interesting numerical coincidence is that (max USB transfer) - (what >> you get) = 4096-3968 = 128 bytes is (almost) the size of the headers >> needed to transfer that much data. > >I was thinking along the same lines. I don't know USB well, but I do know >that those numbers were close enough to warrant investigating the >relationship between them. > >> I think what you're seeing is the internal buffering of the USB data >> stream. You'll need some form of higher-level buffering to smooth >> that out. > >Shouldn't the InputStreamReader() and BufferedReader() provide this type of >buffering? Isn't that the idea behind those? > >> All hypotheses need to be tested. In this case, a test would be to >> check for missing data. If this idea is right, you'll get _all_ the >> data, but you won't be missing characters. > >I did start looking at the data. -- I'm getting weird results. > >I tried this: > >loopzz = 0; > >for (looptwo = 0; looptwo < 100000; looptwo++) { >while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > >}} > >So I'm reading one character at a time. The good news is that loopzz is >exactly 15238 at the end of the routine, which is perfectly correct. I >picked looptwo value out of thin air. > >The weird results come in terms of the values, the data isn't correct at >least in one case. Look here: > >0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > >This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). >But the 0x89 was replaced by 0x2030. Why the heck would the returned value >be 0x2030?? Why is the returned byte completely out of range? Why the >multibyte return? > >>From InputStream in the API: > >read >public abstract int read() > throws IOExceptionReads the next byte of data from the >input stream. The value byte is returned as an int in the range 0 to 255. If >no byte is available because the end of the stream has been reached, the >value -1 is returned. This method blocks until input data is available, the >end of the stream is detected, or an exception is thrown. >Value should be 0-255. > > >In my application time is really critical, reading 1 byte at a time is >probably not going to work. > >Thanks Eric & Bob for looking at this. > >Keith > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 15:10:11 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 17:10:11 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Bob said ..... > Java's "char" type is Unicode. I think what you're seeing is a bug > in the byte -> Unicode translation. Bob -- I think you hit the nail on the head. I was just coming to the same realization here. I knew that something funny was going on because the same bytes always got "corrupted." I'm pretty sure its in the InputStreamReader() functionality where the conversion junk is happening. Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. I don't know if simply changing the cast is going to work. Since the conversion is happening upstream (pun intended), I don't think my cast is doing this. Also I think the compiler forced me to use the cast. I'm still playing around, and I'll report back once I nail it down. Thanks!! Keith From tjarvi at qbang.org Sat Mar 3 15:59:46 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 15:59:46 -0700 (MST) Subject: [Rxtx] Win64 rxtx Testers? Message-ID: I have compiled win64 binaries of rxtx. Are there any users interested in testing them? If so, I'll look into putting them on the web site. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Mar 3 15:35:06 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 14:35:06 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: Because of this and similar problems, JMRI does all it's serial IO using +only+ byte values. It's a but of a pain, as Java wants to go to char and int types a little too aggressively, but it does solve the "uncontrolled conversions" problems. Bob At 5:10 PM -0500 3/3/07, Keith wrote: >Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > >Bob -- I think you hit the nail on the head. > >I was just coming to the same realization here. I knew that something funny >was going on because the same bytes always got "corrupted." > >I'm pretty sure its in the InputStreamReader() functionality where the >conversion junk is happening. > >Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > >I don't know if simply changing the cast is going to work. Since the >conversion is happening upstream (pun intended), I don't think my cast is >doing this. Also I think the compiler forced me to use the cast. -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mark at mdsh.com Sun Mar 4 11:01:33 2007 From: mark at mdsh.com (Mark Himsley) Date: Sun, 04 Mar 2007 18:01:33 +0000 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: <5C01AC72C200388815C04982@bedroom.mdsh.local> On 03 March 2007 14:38 -0500 Keith wrote: > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT > consistent. Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? It looks like you need to use DataInputStream and DataOutputStream. -- Mark Himsley From tjarvi at qbang.org Sun Mar 4 11:35:08 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 11:35:08 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" > > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > > * Line #21 - Not sure if you need a (TM) mark for > the term "Sun" > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > OK. I'm going through this today. Some groups ask if rxtx could be under their license also. I think this is a good example of why I resist multiple licenses and focus on why the current license may not be usable by them. The RXTX project is a convergence of hobby and commercial interests. I happen to do both right now. The problem with licensing is we have to stay on top of them as they change. Clearly, adding more licenses will not make this easier. I'm acting as the hobby person today. RXTX always favors the hobby people. But as we move forward, I'm going to need to bring this to lawyers at work and explain to them what is going on. Others here may have to do this also. I don't anticipate problems or unexpected changes. The goal is a consistant, comprehendable and usable license as close to what we have now as possible. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 14:52:10 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 14:52:10 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (1/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: I'm breaking this into two parts. I expect the second part will need more attention. Comments first, then the changed material below. On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > Thanks > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. OK. RXTX for consitent use. java should not be capitalized because it does not only mean Sun [TM] Java [TM]. An example of this not meaning Java is when people use RXTX with GCJ. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". There are not any contributors that are in all of RXTX yet but I did update the comment to try to reflect the current situation without making it a nightmare to maintain. I looked to see how the Linux kernel does it as a reference point. > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" The URL can be problematic. I have done so below with a time reference. GNU does not provide version information in their URLS. I picture this being a problem when the version 3 comes out. > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > This will be corrected when the copy is updated to the version linked below. ---------------- begin proposed material involved -------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. ----------------- end proposed material involved -------------------- I'll be looking at the linking issue again next. That should be all that remains other than including the 2.1 version. Let me know if you have problems with anything here. I do not want to dilute the material I post next with these housekeeping tasks. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 16:08:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 16:08:36 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: For those that are wondering what is going on here, this next bit is the meat of the changes. We agreed a long time ago to put this disclaimer in. We did a so so job. It was in rxtx 2.0, not well written, ... So some groups using rxtx that would like to ship rxtx so users don't need to download, install, go to the mail-list to find why it failed, ... Then their legal teams tell them section 5 paragraph 2 is a show stopper. That was never the intent. Now going through what remains... > and might need a (TM) suffix to make Sun happy. Added disclaimer at the ended 'all trademarks belong...' > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. OK. As you can see I was trying to adjust GNU text there for the LGPL. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. used dynamically linked terminology. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". I tried to address this more upfront with an intent statement. Let me know if you have problems with it. I also tried to make it a little more clear what was derived from the GNU solution by moving the link location closer to GNU's suggestion. > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > Thats the intent. Here is the combined fixes. Note that only the material in /*-- --*/ is being touched. The new GPL license is there but unmodified. ------------------------ begin proposed new license ------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. | | An executable that contains no derivative of any portion of RXTX, but | is designed to work with RXTX by being dynamically linked with it, | is considered a "work that uses the Library" subject to the terms and | conditions of the GNU Lesser General Public License. | | The following has been added to the RXTX License to remove | any confusion about linking to RXTX. We want to allow in part what | section 5, paragraph 2 of the LGPL does not permit in the special | case of linking over a controlled interface. The intent is to add a | Java Specification Request or standards body defined interface in the | future as another exception but one is not currently available. | | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface | | As a special exception, the copyright holders of RXTX give you | permission to link RXTX with independent modules that communicate with | RXTX solely through the Sun Microsytems CommAPI interface version 2, | regardless of the license terms of these independent modules, and to copy | and distribute the resulting combined work under terms of your choice, | provided that every copy of the combined work is accompanied by a complete | copy of the source code of RXTX (the version of RXTX used to produce the | combined work), being distributed under the terms of the GNU Lesser General | Public License plus this exception. An independent module is a | module which is not derived from or based on RXTX. | | Note that people who make modified versions of RXTX are not obligated | to grant this special exception for their modified versions; it is | their choice whether to do so. The GNU Lesser General Public License | gives permission to release a modified version without this exception; this | exception also makes it possible to release a modified version which | carries forward this exception. | | You should have received a copy of the GNU Lesser General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA | All trademarks belong to their respective owners. --------------------------------------------------------------------------*/ The original GNU Lesser General Public License Follows. GNU LESSER GENERAL PUBLIC LICENSE Version 2.1, February 1999 Copyright (C) 1991, 1999 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. [This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence the version number 2.1.] Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This license, the Lesser General Public License, applies to some specially designated software packages--typically libraries--of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below. When we speak of free software, we are referring to freedom of use, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish); that you receive source code or can get it if you want it; that you can change the software and use pieces of it in new free programs; and that you are informed that you can do these things. To protect your rights, we need to make restrictions that forbid distributors to deny you these rights or to ask you to surrender these rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library or if you modify it. For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights. We protect your rights with a two-step method: (1) we copyright the library, and (2) we offer you this license, which gives you legal permission to copy, distribute and/or modify the library. To protect each distributor, we want to make it very clear that there is no warranty for the free library. Also, if the library is modified by someone else and passed on, the recipients should know that what they have is not the original version, so that the original author's reputation will not be affected by problems that might be introduced by others. Finally, software patents pose a constant threat to the existence of any free program. We wish to make sure that a company cannot effectively restrict the users of a free program by obtaining a restrictive license from a patent holder. Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license. Most GNU software, including some libraries, is covered by the ordinary GNU General Public License. This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs. When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library. We call this license the "Lesser" General Public License because it does Less to protect the user's freedom than the ordinary General Public License. It also provides other free software developers Less of an advantage over competing non-free programs. These disadvantages are the reason we use the ordinary General Public License for many libraries. However, the Lesser license provides advantages in certain special circumstances. For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License. In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software. For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU operating system, as well as its variant, the GNU/Linux operating system. Although the Lesser General Public License is Less protective of the users' freedom, it does ensure that the user of a program that is linked with the Library has the freedom and the wherewithal to run that program using a modified version of the Library. The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, whereas the latter must be combined with the library in order to run. GNU LESSER GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License Agreement applies to any software library or other program which contains a notice placed by the copyright holder or other authorized party saying it may be distributed under the terms of this Lesser General Public License (also called "this License"). Each licensee is addressed as "you". A "library" means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables. The "Library", below, refers to any such software library or work which has been distributed under these terms. A "work based on the Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term "modification".) "Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library. Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does. 1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) The modified work must itself be a software library. b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change. c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License. d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful. (For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library. In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. 4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange. If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code. 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables. When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law. If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.) Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself. 6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications. You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things: a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.) b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. c) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution. d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place. e) Verify that the user has already received a copy of these materials or that you have already sent this user a copy. For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute. 7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things: a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above. b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work. 8. You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 9. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Library (or any work based on the Library), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Library or works based on it. 10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties with this License. 11. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply, and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 12. If the distribution and/or use of the Library is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Library under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 13. The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation. 14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Libraries If you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the ordinary General Public License). To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Also add information on how to contact you by electronic and paper mail. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the library, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the library `Frob' (a library for tweaking knobs) written by James Random Hacker. , 1 April 1990 Ty Coon, President of Vice That's all there is to it! ------------------------ end of proposed license ------------------ -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sun Mar 4 16:26:04 2007 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 04 Mar 2007 17:26:04 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <45EB558C.3010609@cox.net> Bob Jacobsen wrote: > Because of this and similar problems, JMRI does all it's serial IO > using +only+ byte values. It's a but of a pain, as Java wants to go > to char and int types a little too aggressively, but it does solve > the "uncontrolled conversions" problems. Anytime that you are reading bytes of data that is not printable, unicode text, in Java, you really need to stay away from the Readers. Use input stream only, or you will see unicode valued byte groups converted to unicode "char" values. Gregg Wonderly From joachim at buechse.de Mon Mar 5 04:23:48 2007 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 5 Mar 2007 12:23:48 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> The behaviour is exactly what you asked for in you code. is = new BufferedReader(new InputStreamReader(port.getInputStream())); Readers return Text (ie unicode chars) not bytes. You instantiate the InputStreamReader without saying which charset you want, which means "platform default". As this is on Windows, it will convert Windows characters to equivalent unicode characters. If you want to read bytes, read bytes not Text. Reading bytes is done with InputStream and BufferedInputStream. BTW: The InputStream and Reader methods that read arrays are not guarenteed to fill up the array. You always have to check what you really got, and advance your index accordingly. A typical "read up to 32k" method looks like this: InputStream is= ... // -- determine the max buffer size int len= is.available(); if (len == 0) { len= 32 * 1024; } // -- read all available data byte[] buffer= new byte[len]; int pos= 0; int read; do { read= is.read(buffer, pos, buffer.length - pos); pos= pos + read; } while (read != -1 && pos < buffer.length); Best regards, Joachim --- Joachim B?chse Phone: +41 44 500 2604 Buechse Consulting Hadlaubsteig 2 CH-8006 Z?rich On 03.03.2007, at 23:10, Keith wrote: > Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > > Bob -- I think you hit the nail on the head. > > I was just coming to the same realization here. I knew that > something funny > was going on because the same bytes always got "corrupted." > > I'm pretty sure its in the InputStreamReader() functionality where the > conversion junk is happening. > > Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > > I don't know if simply changing the cast is going to work. Since the > conversion is happening upstream (pun intended), I don't think my > cast is > doing this. Also I think the compiler forced me to use the cast. > > I'm still playing around, and I'll report back once I nail it down. > > Thanks!! > > Keith > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Mon Mar 5 07:25:46 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 05 Mar 2007 08:25:46 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> Message-ID: <45EC286A.8060608@cox.net> Joachim Buechse wrote: > BTW: The InputStream and Reader methods that read arrays are not > guarenteed to fill up the array. You always have to check what you > really got, and advance your index accordingly. A typical "read up to > 32k" method looks like this: > > InputStream is= ... > // -- determine the max buffer size > int len= is.available(); > if (len == 0) { > len= 32 * 1024; > } > // -- read all available data > byte[] buffer= new byte[len]; > int pos= 0; > int read; > do { > read= is.read(buffer, pos, buffer.length - pos); > pos= pos + read; > } while (read != -1 && pos < buffer.length); > My preferred structure is. byte arr[ len ]; int cnt; int off = 0; while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { off += cnt; } This keeps you from adding -1 to pos when the read returns -1. It also skips out when the read is 0 bytes which, is not a described EOF in InputStream java docs, but is a condition I want to be aware of. Gregg Wonderly From joachim at buechse.de Tue Mar 6 02:52:58 2007 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 6 Mar 2007 10:52:58 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <45EC286A.8060608@cox.net> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: The code I copied was from a file resource reader, it shouldn't really be applied to networking/external IO code. Mea culpa. However aborting when you get 0 from read is not always what you want either (you kind of indicated that already). Some unix java implementations will return 0 if the kernel read was aborted with EINTER, which is rarely the point where you want to abort your read - at least not without further checks. A "complete" solution always depends on the events you need to handle and the time the total read could take in reality. In some cases it's worth checking Thread.isInterrupted() in the loop, some code re-loops on 0 but only a limited number of times, some check a total timeout limit, etc... Best regards, Joachim On 05.03.2007, at 15:25, Gregg Wonderly wrote: > My preferred structure is. > > byte arr[ len ]; > int cnt; > int off = 0; > while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { > off += cnt; > } > > This keeps you from adding -1 to pos when the read returns -1. It > also skips > out when the read is 0 bytes which, is not a described EOF in > InputStream java > docs, but is a condition I want to be aware of. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Mar 6 14:47:44 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 Mar 2007 14:47:44 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: Just FYI, rxtx will usually not break out on EINTER. The code in the native library usually does something close to this: do { read(...) } while ( !done && errno==EINTR ); Obviously there is a little more involved but it will retry on EINTER if not done. On Tue, 6 Mar 2007, Joachim Buechse wrote: > The code I copied was from a file resource reader, it shouldn't > really be applied to networking/external IO code. Mea culpa. > > However aborting when you get 0 from read is not always what you want > either (you kind of indicated that already). Some unix java > implementations will return 0 if the kernel read was aborted with > EINTER, which is rarely the point where you want to abort your read - > at least not without further checks. A "complete" solution always > depends on the events you need to handle and the time the total read > could take in reality. In some cases it's worth checking > Thread.isInterrupted() in the loop, some code re-loops on 0 but only > a limited number of times, some check a total timeout limit, etc... > > Best regards, > Joachim > > On 05.03.2007, at 15:25, Gregg Wonderly wrote: >> My preferred structure is. >> >> byte arr[ len ]; >> int cnt; >> int off = 0; >> while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { >> off += cnt; >> } >> >> This keeps you from adding -1 to pos when the read returns -1. It >> also skips >> out when the read is 0 bytes which, is not a described EOF in >> InputStream java >> docs, but is a condition I want to be aware of. >> >> Gregg Wonderly >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 gjhanna at gmail.com Thu Mar 8 13:42:52 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Fri, 9 Mar 2007 09:42:52 +1300 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? Message-ID: I've just struck an issue using rxtx in a multi-threaded environment: If I have 3 threads trying to open *the same* comm-port I get a deadlock in CommPortIdentifier.open If I have just 2, it works fine - I get a PortInUseException which is nice and I can handle it. The 3 thread->deadlock thing is causing me issues. (Sample code below). This is from the java thread-dump Found one Java-level deadlock: ============================= "Thread-2": waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object ), which is held by "Thread-1" "Thread-1": waiting to lock monitor 0x0003e9cc (object 0x2450e108, a gnu.io.CommPortIdentifier), which is held by "Thread-2" Java stack information for the threads listed above: =================================================== "Thread-2": at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:329) - waiting to lock <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) "Thread-1": at java.lang.Object.wait(Native Method) - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) - locked <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) (Apart from this, rxtx is working fantastically for us). I'm thinking I'll have to implement some sort of locking mechanism that *doesn't* use java synchronization to prevent this situation. (Which doesn't sound like a good idea to me). Any ideas? Thanks, Greg Hanna ============= RXTXLockTest.java ======================================== import gnu.io.CommPort; import gnu.io.CommPortIdentifier; /** * @author Greg Hanna * Minimal code to create a deadlock with rxtx in multithreaded open */ public class RXTXLockTest { public static void main(String[] args) { try { CommPortIdentifier cpiCom1 = CommPortIdentifier.getPortIdentifier ("COM14"); OpenThread t1 = new OpenThread (" one ", cpiCom1); OpenThread t2 = new OpenThread (" two ", cpiCom1); OpenThread t3 = new OpenThread (" 003 ", cpiCom1); t1.start(); t2.start(); t3.start(); // comment this out and it runs with (expected) PortInUseException } catch (Exception e) { e.printStackTrace(); } } } class OpenThread extends Thread { String name; CommPortIdentifier cpi; CommPort cp; public OpenThread (String name, CommPortIdentifier cpi) { this.name = name; this.cpi = cpi; System.out.println (System.currentTimeMillis() + name + " thread created"); } public void run () { try { System.out.println (System.currentTimeMillis() + name + " opening"); cp = cpi.open(name, 2000); System.out.println (System.currentTimeMillis() + name + " opened - sleeping"); sleep (2000); // do the serial comms with the device. System.out.println (System.currentTimeMillis() + name + " slept - closing"); cp.close(); System.out.println (System.currentTimeMillis() + name + " closed - exiting"); } catch (Exception e) { System.out.println ("Error in thread: " + name ); e.printStackTrace(); } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070308/d9a163c5/attachment-0004.html From eu259473 at tele2.it Fri Mar 9 02:46:20 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 09 Mar 2007 10:46:20 +0100 Subject: [Rxtx] rxtx: tru64 unix make fails Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070309/3b654523/attachment-0004.html From lyon at docjava.com Fri Mar 9 03:58:32 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 Mar 2007 05:58:32 -0500 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi All, The deadlock issue is one that I have been thinking about for some time now. It seems to me that we need a resource manager that enables assignment to a known process. The one thing that seems important about serial ports is that two applications should not use the same serial port at the same time. When this happens, it throws an exception. OK. The exception is a response to a lock condition that arises from an unavailable resource. An abstract implementation (not born of native methods) might assign a serial port to an application, until the application releases it (or is forced to release it by some kill mechanism). Some resources (like a registry) can be reused. But others, like the serial port, cannot. In the case of the serial port, we would like, I think, to have the flyweight design pattern without sharing and with object assignment tracking. A means of breaking deadlock (like a leasing mechanism) seems very useful, to me. My guess is that we can serialize the state of the Parametric Singleton Pattern (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) into the Preferences of the System. Preferences.systemRoot() might help with that. When a resource is checked out, the lease time and owner are listed. A thread that does this can be killed, but applications outside of Java are problematic. There is a compelling problem here. It is not just serial ports. Sound cards, cameras, microphones, files, tape drives, etc. All are consumed resources that are assigned to an application (or user) and deprive other applications, or users, from use. What, if anything, should we do? At present we throw PortInUseExceptions. Is that it? Can we do better? OK, the port is in use. Now what? Do I have to be root to go remove lock files and kill applications? Is there a better way? Thanks! - Doug >I've just struck an issue using rxtx in a multi-threaded environment: > >If I have 3 threads trying to open *the same* >comm-port I get a deadlock in >CommPortIdentifier.open >If I have just 2, it works fine - I get a >PortInUseException which is nice and I can >handle it. > >The 3 thread->deadlock thing is causing me issues. >(Sample code below). > >This is from the java thread-dump > >Found one Java-level deadlock: >============================= >"Thread-2": > waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), > which is held by "Thread-1" >"Thread-1": > waiting to lock monitor 0x0003e9cc (object >0x2450e108, a gnu.io.CommPortIdentifier ), > which is held by "Thread-2" > >Java stack information for the threads listed above: >=================================================== >"Thread-2": > at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) > - waiting to lock <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) >"Thread-1": > at java.lang.Object.wait(Native Method) > - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) > - locked <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) > > >(Apart from this, rxtx is working fantastically for us). > >I'm thinking I'll have to implement some sort of >locking mechanism that *doesn't* use java >synchronization to prevent this situation. >(Which doesn't sound like a good idea to me). > >Any ideas? > >Thanks, > >Greg Hanna > >============= RXTXLockTest.java ======================================== > >import gnu.io.CommPort; >import gnu.io.CommPortIdentifier; > >/** > * @author Greg Hanna > * Minimal code to create a deadlock with rxtx in multithreaded open > */ >public class RXTXLockTest { > ? > ?public static void main(String[] args) { > ?try { > ?CommPortIdentifier cpiCom1 = >CommPortIdentifier.getPortIdentifier ("COM14"); > ?OpenThread t1 = new OpenThread (" one ", cpiCom1); > ?OpenThread t2 = new OpenThread (" two ", cpiCom1); > ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); > ?t1.start(); > ?t2.start(); > ?t3.start(); // comment this out >and it runs with (expected) PortInUseException > ?} catch (Exception e) { > ?e.printStackTrace(); > ?} > ?} >} > >class OpenThread extends Thread { > ?String name; > ?CommPortIdentifier cpi; > ?CommPort cp; > ?public OpenThread (String name, CommPortIdentifier cpi) { > ? this.name = name; > ?this.cpi = cpi; > ?System.out.println >(System.currentTimeMillis() + name + " thread >created"); > ?} > ?public void run () { > ?try { > ?System.out.println >(System.currentTimeMillis() + name + " opening"); > ?cp = cpi.open(name, 2000); > ?System.out.println >(System.currentTimeMillis() + name + " opened - >sleeping"); > ?sleep (2000); // do the serial comms with the device. > ?System.out.println >(System.currentTimeMillis() + name + " slept - >closing"); > ?cp.close(); > ?System.out.println >(System.currentTimeMillis() + name + " closed - >exiting"); > ?} catch (Exception e) { > System.out.println ("Error in thread: " + name ); > ?e.printStackTrace(); > ?} > ?} >} > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Mar 9 06:37:45 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 Mar 2007 06:37:45 -0700 (MST) Subject: [Rxtx] rxtx: tru64 unix make fails In-Reply-To: References: Message-ID: On Fri, 9 Mar 2007, "Giuseppe Marchese" wrote: > Sorry for delay. > ? > This is log for ./configure and make > error. > ? > thanks for attention > ? > Make: '%.java,$(TOP)/$(CLASSDEST)/%.class,$(wildcard $(SPATH)/*.java)': extra chars.? > Stop. > Hi Giuseppe You need to use GNU make with the Makefile. I suspect the tru64 make is not happy with those rules. > configure: exit 0 Looks like configure is fairly happy. From tjarvi at qbang.org Sat Mar 10 07:43:51 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 07:43:51 -0700 (MST) Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi Doug I have very little time to look into this further but what we could do is open up an rxtx 3 devel branch in which a proof of concept could be worked on. It could be the proof of concept for a JSR others including Sun could look at/work on or parts of it could be recycled in a JSR. I'm working very hard on rxtx right now but it does not show. I'm looking at win64, mac intel/ppc, usb bluetooth and usb serial dongles. Some are going to be more tested than others but they are all on the plate. I'll be pushing all the fixes upstream when they are done. So I'm very busy in 2.1 but we could open a new branch. On Fri, 9 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > The deadlock issue is one that I have been thinking about > for some time now. > It seems to me that we need a resource manager that enables assignment > to a known process. > > The one thing that seems important about serial > ports is that two applications should not use the > same serial port at the same time. When this > happens, it throws an exception. > OK. > > The exception is a response to a lock condition that > arises from an unavailable resource. > > An abstract implementation (not born of native methods) might > assign a serial port to an application, until the > application releases it (or is forced to release > it by some kill mechanism). > > Some resources (like a registry) can be reused. > But others, like the serial port, > cannot. > > In the case of the serial port, we would like, I think, to > have the flyweight design pattern > without sharing and with object assignment tracking. > A means of breaking deadlock (like a leasing > mechanism) seems very useful, to me. > > My guess is that we can serialize the state of the Parametric Singleton Pattern > (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) > into the Preferences of the System. Preferences.systemRoot() might help > with that. When a resource is checked out, the lease time and owner are > listed. A thread that does this can be killed, but applications outside of Java > are problematic. > > There is a compelling problem here. It is not just serial ports. > Sound cards, cameras, microphones, files, tape drives, etc. All are consumed > resources that are assigned to an application (or > user) and deprive other applications, > or users, from use. > > What, if anything, should we do? At present we throw PortInUseExceptions. > Is that it? > Can we do better? > OK, the port is in use. Now what? > Do I have to be root to go remove lock files and kill applications? > Is there a better way? > > Thanks! > - Doug > >> I've just struck an issue using rxtx in a multi-threaded environment: >> >> If I have 3 threads trying to open *the same* >> comm-port I get a deadlock in >> CommPortIdentifier.open >> If I have just 2, it works fine - I get a >> PortInUseException which is nice and I can >> handle it. >> >> The 3 thread->deadlock thing is causing me issues. >> (Sample code below). >> >> This is from the java thread-dump >> >> Found one Java-level deadlock: >> ============================= >> "Thread-2": >> waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), >> which is held by "Thread-1" >> "Thread-1": >> waiting to lock monitor 0x0003e9cc (object >> 0x2450e108, a gnu.io.CommPortIdentifier ), >> which is held by "Thread-2" >> >> Java stack information for the threads listed above: >> =================================================== >> "Thread-2": >> at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) >> - waiting to lock <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> "Thread-1": >> at java.lang.Object.wait(Native Method) >> - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) >> - locked <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> >> >> (Apart from this, rxtx is working fantastically for us). >> >> I'm thinking I'll have to implement some sort of >> locking mechanism that *doesn't* use java >> synchronization to prevent this situation. >> (Which doesn't sound like a good idea to me). >> >> Any ideas? >> >> Thanks, >> >> Greg Hanna >> >> ============= RXTXLockTest.java ======================================== >> >> import gnu.io.CommPort; >> import gnu.io.CommPortIdentifier; >> >> /** >> * @author Greg Hanna >> * Minimal code to create a deadlock with rxtx in multithreaded open >> */ >> public class RXTXLockTest { >> ? >> ?public static void main(String[] args) { >> ?try { >> ?CommPortIdentifier cpiCom1 = >> CommPortIdentifier.getPortIdentifier ("COM14"); >> ?OpenThread t1 = new OpenThread (" one ", cpiCom1); >> ?OpenThread t2 = new OpenThread (" two ", cpiCom1); >> ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); >> ?t1.start(); >> ?t2.start(); >> ?t3.start(); // comment this out >> and it runs with (expected) PortInUseException >> ?} catch (Exception e) { >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> class OpenThread extends Thread { >> ?String name; >> ?CommPortIdentifier cpi; >> ?CommPort cp; >> ?public OpenThread (String name, CommPortIdentifier cpi) { >> ? this.name = name; >> ?this.cpi = cpi; >> ?System.out.println >> (System.currentTimeMillis() + name + " thread >> created"); >> ?} >> ?public void run () { >> ?try { >> ?System.out.println >> (System.currentTimeMillis() + name + " opening"); >> ?cp = cpi.open(name, 2000); >> ?System.out.println >> (System.currentTimeMillis() + name + " opened - >> sleeping"); >> ?sleep (2000); // do the serial comms with the device. >> ?System.out.println >> (System.currentTimeMillis() + name + " slept - >> closing"); >> ?cp.close(); >> ?System.out.println >> (System.currentTimeMillis() + name + " closed - >> exiting"); >> ?} catch (Exception e) { >> System.out.println ("Error in thread: " + name ); >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 mm at UDel.Edu Sat Mar 10 14:48:32 2007 From: mm at UDel.Edu (Mike Markowski) Date: Sat, 10 Mar 2007 16:48:32 -0500 Subject: [Rxtx] rxtx and Sun's comm api Message-ID: <45F327B0.2060004@udel.edu> Hi all, I joined the list a few days ago and apologize for what is likely a frequently asked question, though I haven't yet found it anywhere. I learned about rxtx.org through the readme on Sun's version 2 of their comms api. They give recommendations in that readme regarding how a better comms api should be written. Is this the aim of rxtx.org? I wrote an app on my linux box using the Sun comms api (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the fact that only linux and Solaris are supported. So I'm glad to find rxtx.org and am just reading up on how make the conversion so Windows users will be able to run the program as well. At the same time I'm just curious if rxtx.org and Sun are both heading in the same direction. Thanks for any background or historical info. Feel free to point me to any www pages if my googling has just completely missed the target! Thanks again, Mike From tjarvi at qbang.org Sat Mar 10 15:35:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 15:35:25 -0700 (MST) Subject: [Rxtx] rxtx and Sun's comm api In-Reply-To: <45F327B0.2060004@udel.edu> References: <45F327B0.2060004@udel.edu> Message-ID: On Sat, 10 Mar 2007, Mike Markowski wrote: > Hi all, > > I joined the list a few days ago and apologize for what is likely a > frequently asked question, though I haven't yet found it anywhere. I > learned about rxtx.org through the readme on Sun's version 2 of their > comms api. They give recommendations in that readme regarding how a > better comms api should be written. Is this the aim of rxtx.org? > > I wrote an app on my linux box using the Sun comms api > (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the > fact that only linux and Solaris are supported. So I'm glad to find > rxtx.org and am just reading up on how make the conversion so Windows > users will be able to run the program as well. At the same time I'm > just curious if rxtx.org and Sun are both heading in the same direction. > > Thanks for any background or historical info. Feel free to point me to > any www pages if my googling has just completely missed the target! > I do not have any news (good or bad) concerning RXTX and Sun working together but perhaps others here do. The main goal of RXTX is to expose POSIX termios interfaces to java users. The future support of javax.comm is questionable. We do not have resources for everything. gnu.io (RXTX 2.1) will be supported going forward and functions the same as CommAPI 2.0. If you have control of the source code you are working with, I would not advise using CommAPI 2.0 javax.comm. We do support CommAPI 2.0 javax.comm for older applications but I do not think that will last much longer for practical reasons. The download interest in CommAPI 2.0 javax.comm support is becomming negligible on this end. There has been discussion of a JSR effort but I do not know of any status change since it was mentioned. One problem with a JSR is that even a light weight process is going to be difficult for RXTX at this time. Maybe that will change in the future but then again it may not. For now, we are just going forward 'as is' in rxtx 2.1 with package gnu.io while trying as a secondary effort to backport the changes to rxtx 2.0 for javax.comm support for users that do not have a choice. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Mar 11 07:19:40 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 11 Mar 2007 08:19:40 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: Hi All, I have been a proponent of a JSR that makes use of RXTX. I have executed the proper agreements with Sun. At this point we are in the: Early Draft Review of Draft Specifications Stage. The best thing to do is to enter the quiet period and create a specification. The question of exactly how we, as a group, want to approach this problem, remains open. Typically, we should have both a specification and a reference implementation. Thus, it would be to our best advantage to have a nice, stable, cross platform RXTX distro that adheres to the groups specification. Now, from a specification standpoint, my personal view on the matter is that we create a series of interfaces, with nice documentation (or at least javadoc). Is this a good idea? Should we have a pure interface specification for the communication API? There are several issues, in my mind, which still weigh on us. Hot-pluggable dongles, long discovery process on pop-up ports, lack of uniformity on device names, lack of uniformity on locking, a precise understanding of how the SerialPortResourceManager works (or even if we should have one). The more questions we answer in our reference implementation, the better our specification will get. RXTX is a good working prototype, but, I don't know if that is what we want to use for a specification. Here is what I have for a CommPortInterface: */ public interface CommPortInterface { /** * @return a string representation of this port. */ String toString(); /** * Gets the name of the communications port. This name should correspond to * something the user can identify, like the label on the hardware. * @return name of the port */ String getName(); /** * @return an input stream that can be used to read data from the * communications port. If the port doesn't support reading data, this * method returns null. *

* The blocking behaviour of this input stream depends on the threshold * and timeout values, as shown below for a read buffer size of n * bytes: * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ThresholdTimeoutBlocking behaviour
StateValueStateValue
disableddisabledblock until data is available
enabledm bytesdisabledblock until min(m, n) bytes are available
disabledenabledt msblock for t ms or until data is available
enabledm bytesenabledt msblock for t ms or until min(m, n) bytes are * available
* @throws java.io.IOException */ InputStream getInputStream() throws IOException; /** * @return an output stream that can be used to send data to the * communications port. If the port doesn't support sending data, this * method returns null. * @throws java.io.IOException */ OutputStream getOutputStream() throws IOException; /** * Closes this communications port. * All PortOwnershipListeners will be? * notified of this change of ownership. Further method calls on this? * object will throw IllegalStateException. Further calls on the? * associated InputStream or OutputStream will throw IOException. *

* Close does not block. Undelivered data is discarded. Blocked read and? * write operations are aborted if the underlying operating systems? * supports an IO abort mechanism. To await the delivery of undelivered? * data call OutputStream.flush() or OutputStream.close() before calling? * Port.close(). */ void close(); /** * Enables receive threshold. * When the specified threshold number of bytes are retrieved, read will * return immediately. * * @param thresh the number of bytes in the input buffer * @throws gnu.io.UnsupportedCommOperationException * if receive threshold is * not supported by the driver * @see #disableReceiveThreshold */ void enableReceiveThreshold(int thresh) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive threshold. * * @see #enableReceiveThreshold */ void disableReceiveThreshold(); /** * @return true if receive threshold is enabled. * * @see #enableReceiveThreshold */ boolean isReceiveThresholdEnabled(); /** * @return the receive threshold value. If receive threshold is diabled * or not supported, this value is meaningless. * * @see #enableReceiveThreshold */ int getReceiveThreshold(); /** * Enables receive timeout. * When the specified number of milliseconds have elapsed, read will * return immediately. * * @param rcvTimeout the number of milliseconds to block for * @throws gnu.io.UnsupportedCommOperationException * if receive timeout is * not supported by the driver * @see #disableReceiveTimeout */ void enableReceiveTimeout(int rcvTimeout) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive timeout. * * @see #enableReceiveTimeout */ void disableReceiveTimeout(); /** * @return true if receive timeout is enabled. * * @see #enableReceiveTimeout */ boolean isReceiveTimeoutEnabled(); /** * @return the receive timeout value. If receive timeout is diabled * or not supported, this value is meaningless. * * @see #enableReceiveTimeout */ int getReceiveTimeout(); /** * Enables receive framing. * The supplied byte value in the input suggests the end of the received * frame, and read returns immediately. Only the low 8 bits of the * supplied value are significant. * * @param framingByte the frame delimiter * @throws gnu.io.UnsupportedCommOperationException * if receive framing is * not supported by the driver * @see #disableReceiveFraming */ void enableReceiveFraming(int framingByte) throws UnsupportedCommOperationException; /** * Disables receive framing. * * @see #enableReceiveFraming */ void disableReceiveFraming(); /** * @return true if receive framing is enabled. * * @see #enableReceiveFraming */ boolean isReceiveFramingEnabled(); /** * @return true if receive framing byte. If receive framing is diabled * or not supported, this value is meaningless. * * @see #enableReceiveFraming */ int getReceiveFramingByte(); /** * Sets the input buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setInputBufferSize(int size); /** * @return the input buffer size. * The driver may choose not to report correct values. */ int getInputBufferSize(); /** * Sets the output buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setOutputBufferSize(int size); /** * @return the output buffer size. * The driver may choose not to report correct values. */ int getOutputBufferSize(); } What do you think of that? Note the wishy washy nature of the spec: The driver may choose to ignore this method. Is that good enough for us? Thanks! - Doug From ra85551 at gmail.com Sun Mar 11 08:44:45 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Sun, 11 Mar 2007 17:44:45 +0300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hello, world! I am writing application that communicates with modem via AT commands. My OS is Linux Kubuntu Feisty Herd, to ensure that my application will run properly under Windows XP I installed VMWare server. When I tried to send AT command and evaluate modem answer under WinXP @ VMWare server, I actually didn't receive anything. I think that VM settings are right, because I do can communicate with modem by using standard HyperTerminall as well as I can do on native Windows. So, why RXTX doesn't work under VM, but works under Linux and pure Windows XP (i tested it there) well? The send/receive method code follows. private String sendATCommand(String command, final String waitFor, final boolean isRegex, boolean isAddCRLF, long timeout) throws BeaconConnectException { final long POLL_PERIOD = 100; final int BUFFER_SIZE = 512; final byte[] buffer = new byte[BUFFER_SIZE]; final InputStream serialInput; final OutputStream serialOutput; try { serialInput = serialPort.getInputStream(); if (command != null) { serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } } catch (IOException e) { throw new MyException("serial I/O error"); } TimerTask task = new TimerTask() { int offset = 0; int bytesRead; public synchronized void run() { try { if (serialInput.available() > 0) { bytesRead = serialInput.read(buffer, offset, BUFFER_SIZE - offset); } else { return; } } catch (IOException e) { // do nothing - maybe next time we'll read something } offset += bytesRead; if (waitFor != null) { String temporary = new String(buffer, 0, offset).trim(); if (isRegex && temporary.matches(waitFor) || temporary.contains(waitFor)) { cancel(); notify(); } } } }; Timer timer = new Timer(); timer.schedule(task, POLL_PERIOD, POLL_PERIOD); synchronized (task) { try { task.wait(timeout); task.cancel(); } catch (InterruptedException e) { } } //Cut off leading and trailing CRs, LFs and zeroes String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); System.out.println(response); return response; } -- Pavel Parkhomenko From tjarvi at qbang.org Sun Mar 11 11:48:22 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:48:22 -0600 (MDT) Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: On Sun, 11 Mar 2007, Pavel Parkhomenko wrote: > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. > > private String sendATCommand(String command, final String waitFor, > final boolean isRegex, boolean isAddCRLF, long timeout) > throws BeaconConnectException > { > final long POLL_PERIOD = 100; > final int BUFFER_SIZE = 512; > final byte[] buffer = new byte[BUFFER_SIZE]; > final InputStream serialInput; > final OutputStream serialOutput; > try > { > serialInput = serialPort.getInputStream(); > if (command != null) > { > serialOutput = serialPort.getOutputStream(); > if (isAddCRLF) > { > command += "\r\n"; > } > System.out.println(command); > serialOutput.write(command.getBytes()); > } > } > catch (IOException e) > { > throw new MyException("serial I/O error"); > } > > TimerTask task = new TimerTask() > { > int offset = 0; > int bytesRead; > public synchronized void run() > { > try > { > if (serialInput.available() > 0) > { > bytesRead = serialInput.read(buffer, offset, > BUFFER_SIZE - offset); > } > else > { > return; > } > } > catch (IOException e) > { > // do nothing - maybe next time we'll read something > } > offset += bytesRead; > if (waitFor != null) > { > String temporary = new String(buffer, 0, offset).trim(); > if (isRegex && temporary.matches(waitFor) || > temporary.contains(waitFor)) > { > cancel(); > notify(); > } > } > } > }; > > Timer timer = new Timer(); > timer.schedule(task, POLL_PERIOD, POLL_PERIOD); > synchronized (task) { > try > { > task.wait(timeout); > task.cancel(); > } > catch (InterruptedException e) > { > } > } > //Cut off leading and trailing CRs, LFs and zeroes > String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); > System.out.println(response); > return response; > } > > > Hi Pavel VMWare should not be a problem. I've used it in the past - though not with a modem. Make sure nothing else is using the modem. Then look in the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an example that should work. Note that modems could care less what OS is on top. If you are trying to match new lines to the OS and sending it to the mode for AT commands, thats probably a mistake. Also it would not hurt to print out the individual bytes that you are sending to make sure they did not get mangled along the path. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 11:55:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:55:48 -0600 (MDT) Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: On Sun, 11 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > I have been a proponent of a JSR that makes > use of RXTX. I have executed the proper agreements with Sun. > > At this point we are in the: > Early Draft Review of Draft Specifications Stage. > > The best thing to do is to enter the quiet period and create > a specification. The question of exactly how we, as a group, > want to approach this problem, remains open. > > Typically, we should have both a specification and a reference > implementation. Thus, it would be to our best advantage to have > a nice, stable, cross platform RXTX distro that adheres to the > groups specification. > > Now, from a specification standpoint, my personal view on the matter is > that we create a series of interfaces, with nice documentation (or at least > javadoc). > > Is this a good idea? Should we have a pure interface specification for > the communication API? > > There are several issues, in my mind, which still weigh on us. > Hot-pluggable dongles, long discovery process on pop-up ports, > lack of uniformity on device names, lack of uniformity on locking, > a precise understanding of how the SerialPortResourceManager > works (or even if we should have one). > > The more questions we answer in our reference implementation, the > better our specification will get. RXTX is a good working prototype, > but, I don't know if that is what we want to use for a specification. > > Here is what I have for a CommPortInterface: > */ > public interface CommPortInterface { Hi Doug, I can start going through the method interfaces later this week and giving feedback. I would suggest that the JSR should not be too generic in nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel drivers that intend to look like EIA232 ports at the kernel driver level. some ideas: EIA232PortInterface TermiosInterface SerialPortInterface Something that differentiates this from thing like USB, I2C, ... which should not have to deal with legacy serial claiming to be the comm api. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 12:52:19 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 12:52:19 -0600 (MDT) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: No news is good news with these posts. I'll start the process of pinging legal a week from Monday on my end if nobody has objections to the proposal. I just want to make sure everyone has time to raise objections. Obviously, anyone can fork from a previous version if they don't like the new license. I suspect we can avoid that though. On Sun, 4 Mar 2007, Trent Jarvi wrote: > > For those that are wondering what is going on here, this > next bit is the meat of the changes. We agreed a long time > ago to put this disclaimer in. We did a so so job. It was > in rxtx 2.0, not well written, ... So some groups using > rxtx that would like to ship rxtx so users don't need to > download, install, go to the mail-list to find why it failed, > ... Then their legal teams tell them section 5 paragraph 2 > is a show stopper. > > That was never the intent. > > > Now going through what remains... > >> and might need a (TM) suffix to make Sun happy. > > Added disclaimer at the ended 'all trademarks belong...' > >> * Line #15ff - static vs. dynamic linking - you did >> not transcribe the text from the "controlled >> interface exception" when writing this text - and >> this was good so, because these terms originally >> refer to the GPL rather than the LGPL. I think though, >> that these 4 lines are the most important ones and >> should thus be really really clear. I hope that I >> meet your original intent with the following >> suggestions: >> 1.) Instead of "A program.." it would be better to >> say "An exectuable.." in order to be closer to >> the LGPL text. > > OK. As you can see I was trying to adjust GNU text there > for the LGPL. > >> 2.) It would be better to say .. "by being dynamically >> linked with it" to clearly indicate that dynamic >> linking is meant. The matter of compilation is >> already covered by the LGPL so mentioning it again >> just leads to confusion. > > used dynamically linked terminology. > >> 3.) It would be better to say .. "is considered a >> work that uses the library in contrast to section >> 5 of the LGPL, so the terms of the LGPL do not >> apply to the resulting executable". > > I tried to address this more upfront with an intent statement. > Let me know if you have problems with it. I also tried to > make it a little more clear what was derived from the GNU > solution by moving the link location closer to GNU's suggestion. > >> >> Note that LGPL section 5 says: ..."is called a >> "work that uses the Library". Such a work, in isolation, >> is not a derivative work of the Library, and therefore >> falls outside the scope of this License." >> The next paragraph of the LGPL is exactly the problematic >> one that I hope is clarified by the exception terms you >> give. >> > > Thats the intent. Here is the combined fixes. Note that only the > material in /*-- --*/ is being touched. The new GPL license is > there but unmodified. > > > ------------------------ begin proposed new license ------------------- > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Lesser General Public > | License as published by the Free Software Foundation; either > | version 2.1 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Lesser General Public License for more details. > | > | An executable that contains no derivative of any portion of RXTX, but > | is designed to work with RXTX by being dynamically linked with it, > | is considered a "work that uses the Library" subject to the terms and > | conditions of the GNU Lesser General Public License. > | > | The following has been added to the RXTX License to remove > | any confusion about linking to RXTX. We want to allow in part what > | section 5, paragraph 2 of the LGPL does not permit in the special > | case of linking over a controlled interface. The intent is to add a > | Java Specification Request or standards body defined interface in the > | future as another exception but one is not currently available. > | > | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface > | > | As a special exception, the copyright holders of RXTX give you > | permission to link RXTX with independent modules that communicate with > | RXTX solely through the Sun Microsytems CommAPI interface version 2, > | regardless of the license terms of these independent modules, and to copy > | and distribute the resulting combined work under terms of your choice, > | provided that every copy of the combined work is accompanied by a complete > | copy of the source code of RXTX (the version of RXTX used to produce the > | combined work), being distributed under the terms of the GNU Lesser General > | Public License plus this exception. An independent module is a > | module which is not derived from or based on RXTX. > | > | Note that people who make modified versions of RXTX are not obligated > | to grant this special exception for their modified versions; it is > | their choice whether to do so. The GNU Lesser General Public License > | gives permission to release a modified version without this exception; this > | exception also makes it possible to release a modified version which > | carries forward this exception. > | > | You should have received a copy of the GNU Lesser General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > | All trademarks belong to their respective owners. > --------------------------------------------------------------------------*/ > > The original GNU Lesser General Public License Follows. > > > GNU LESSER GENERAL PUBLIC LICENSE > Version 2.1, February 1999 > > Copyright (C) 1991, 1999 Free Software Foundation, Inc. > 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > Everyone is permitted to copy and distribute verbatim copies > of this license document, but changing it is not allowed. > > [This is the first released version of the Lesser GPL. It also counts > as the successor of the GNU Library Public License, version 2, hence > the version number 2.1.] > > Preamble > > The licenses for most software are designed to take away your > freedom to share and change it. By contrast, the GNU General Public > Licenses are intended to guarantee your freedom to share and change > free software--to make sure the software is free for all its users. > > This license, the Lesser General Public License, applies to some > specially designated software packages--typically libraries--of the > Free Software Foundation and other authors who decide to use it. You > can use it too, but we suggest you first think carefully about whether > this license or the ordinary General Public License is the better > strategy to use in any particular case, based on the explanations below. > > When we speak of free software, we are referring to freedom of use, > not price. Our General Public Licenses are designed to make sure that > you have the freedom to distribute copies of free software (and charge > for this service if you wish); that you receive source code or can get > it if you want it; that you can change the software and use pieces of > it in new free programs; and that you are informed that you can do > these things. > > To protect your rights, we need to make restrictions that forbid > distributors to deny you these rights or to ask you to surrender these > rights. These restrictions translate to certain responsibilities for > you if you distribute copies of the library or if you modify it. > > For example, if you distribute copies of the library, whether gratis > or for a fee, you must give the recipients all the rights that we gave > you. You must make sure that they, too, receive or can get the source > code. If you link other code with the library, you must provide > complete object files to the recipients, so that they can relink them > with the library after making changes to the library and recompiling > it. And you must show them these terms so they know their rights. > > We protect your rights with a two-step method: (1) we copyright the > library, and (2) we offer you this license, which gives you legal > permission to copy, distribute and/or modify the library. > > To protect each distributor, we want to make it very clear that > there is no warranty for the free library. Also, if the library is > modified by someone else and passed on, the recipients should know > that what they have is not the original version, so that the original > author's reputation will not be affected by problems that might be > introduced by others. > > Finally, software patents pose a constant threat to the existence of > any free program. We wish to make sure that a company cannot > effectively restrict the users of a free program by obtaining a > restrictive license from a patent holder. Therefore, we insist that > any patent license obtained for a version of the library must be > consistent with the full freedom of use specified in this license. > > Most GNU software, including some libraries, is covered by the > ordinary GNU General Public License. This license, the GNU Lesser > General Public License, applies to certain designated libraries, and > is quite different from the ordinary General Public License. We use > this license for certain libraries in order to permit linking those > libraries into non-free programs. > > When a program is linked with a library, whether statically or using > a shared library, the combination of the two is legally speaking a > combined work, a derivative of the original library. The ordinary > General Public License therefore permits such linking only if the > entire combination fits its criteria of freedom. The Lesser General > Public License permits more lax criteria for linking other code with > the library. > > We call this license the "Lesser" General Public License because it > does Less to protect the user's freedom than the ordinary General > Public License. It also provides other free software developers Less > of an advantage over competing non-free programs. These disadvantages > are the reason we use the ordinary General Public License for many > libraries. However, the Lesser license provides advantages in certain > special circumstances. > > For example, on rare occasions, there may be a special need to > encourage the widest possible use of a certain library, so that it becomes > a de-facto standard. To achieve this, non-free programs must be > allowed to use the library. A more frequent case is that a free > library does the same job as widely used non-free libraries. In this > case, there is little to gain by limiting the free library to free > software only, so we use the Lesser General Public License. > > In other cases, permission to use a particular library in non-free > programs enables a greater number of people to use a large body of > free software. For example, permission to use the GNU C Library in > non-free programs enables many more people to use the whole GNU > operating system, as well as its variant, the GNU/Linux operating > system. > > Although the Lesser General Public License is Less protective of the > users' freedom, it does ensure that the user of a program that is > linked with the Library has the freedom and the wherewithal to run > that program using a modified version of the Library. > > The precise terms and conditions for copying, distribution and > modification follow. Pay close attention to the difference between a > "work based on the library" and a "work that uses the library". The > former contains code derived from the library, whereas the latter must > be combined with the library in order to run. > > GNU LESSER GENERAL PUBLIC LICENSE > TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION > > 0. This License Agreement applies to any software library or other > program which contains a notice placed by the copyright holder or > other authorized party saying it may be distributed under the terms of > this Lesser General Public License (also called "this License"). > Each licensee is addressed as "you". > > A "library" means a collection of software functions and/or data > prepared so as to be conveniently linked with application programs > (which use some of those functions and data) to form executables. > > The "Library", below, refers to any such software library or work > which has been distributed under these terms. A "work based on the > Library" means either the Library or any derivative work under > copyright law: that is to say, a work containing the Library or a > portion of it, either verbatim or with modifications and/or translated > straightforwardly into another language. (Hereinafter, translation is > included without limitation in the term "modification".) > > "Source code" for a work means the preferred form of the work for > making modifications to it. For a library, complete source code means > all the source code for all modules it contains, plus any associated > interface definition files, plus the scripts used to control compilation > and installation of the library. > > Activities other than copying, distribution and modification are not > covered by this License; they are outside its scope. The act of > running a program using the Library is not restricted, and output from > such a program is covered only if its contents constitute a work based > on the Library (independent of the use of the Library in a tool for > writing it). Whether that is true depends on what the Library does > and what the program that uses the Library does. > > 1. You may copy and distribute verbatim copies of the Library's > complete source code as you receive it, in any medium, provided that > you conspicuously and appropriately publish on each copy an > appropriate copyright notice and disclaimer of warranty; keep intact > all the notices that refer to this License and to the absence of any > warranty; and distribute a copy of this License along with the > Library. > > You may charge a fee for the physical act of transferring a copy, > and you may at your option offer warranty protection in exchange for a > fee. > > 2. You may modify your copy or copies of the Library or any portion > of it, thus forming a work based on the Library, and copy and > distribute such modifications or work under the terms of Section 1 > above, provided that you also meet all of these conditions: > > a) The modified work must itself be a software library. > > b) You must cause the files modified to carry prominent notices > stating that you changed the files and the date of any change. > > c) You must cause the whole of the work to be licensed at no > charge to all third parties under the terms of this License. > > d) If a facility in the modified Library refers to a function or a > table of data to be supplied by an application program that uses > the facility, other than as an argument passed when the facility > is invoked, then you must make a good faith effort to ensure that, > in the event an application does not supply such function or > table, the facility still operates, and performs whatever part of > its purpose remains meaningful. > > (For example, a function in a library to compute square roots has > a purpose that is entirely well-defined independent of the > application. Therefore, Subsection 2d requires that any > application-supplied function or table used by this function must > be optional: if the application does not supply it, the square > root function must still compute square roots.) > > These requirements apply to the modified work as a whole. If > identifiable sections of that work are not derived from the Library, > and can be reasonably considered independent and separate works in > themselves, then this License, and its terms, do not apply to those > sections when you distribute them as separate works. But when you > distribute the same sections as part of a whole which is a work based > on the Library, the distribution of the whole must be on the terms of > this License, whose permissions for other licensees extend to the > entire whole, and thus to each and every part regardless of who wrote > it. > > Thus, it is not the intent of this section to claim rights or contest > your rights to work written entirely by you; rather, the intent is to > exercise the right to control the distribution of derivative or > collective works based on the Library. > > In addition, mere aggregation of another work not based on the Library > with the Library (or with a work based on the Library) on a volume of > a storage or distribution medium does not bring the other work under > the scope of this License. > > 3. You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. To do > this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version 2, > instead of to this License. (If a newer version than version 2 of the > ordinary GNU General Public License has appeared, then you can specify > that version instead if you wish.) Do not make any other change in > these notices. > > Once this change is made in a given copy, it is irreversible for > that copy, so the ordinary GNU General Public License applies to all > subsequent copies and derivative works made from that copy. > > This option is useful when you wish to copy part of the code of > the Library into a program that is not a library. > > 4. You may copy and distribute the Library (or a portion or > derivative of it, under Section 2) in object code or executable form > under the terms of Sections 1 and 2 above provided that you accompany > it with the complete corresponding machine-readable source code, which > must be distributed under the terms of Sections 1 and 2 above on a > medium customarily used for software interchange. > > If distribution of object code is made by offering access to copy > from a designated place, then offering equivalent access to copy the > source code from the same place satisfies the requirement to > distribute the source code, even though third parties are not > compelled to copy the source along with the object code. > > 5. A program that contains no derivative of any portion of the > Library, but is designed to work with the Library by being compiled or > linked with it, is called a "work that uses the Library". Such a > work, in isolation, is not a derivative work of the Library, and > therefore falls outside the scope of this License. > > However, linking a "work that uses the Library" with the Library > creates an executable that is a derivative of the Library (because it > contains portions of the Library), rather than a "work that uses the > library". The executable is therefore covered by this License. > Section 6 states terms for distribution of such executables. > > When a "work that uses the Library" uses material from a header file > that is part of the Library, the object code for the work may be a > derivative work of the Library even though the source code is not. > Whether this is true is especially significant if the work can be > linked without the Library, or if the work is itself a library. The > threshold for this to be true is not precisely defined by law. > > If such an object file uses only numerical parameters, data > structure layouts and accessors, and small macros and small inline > functions (ten lines or less in length), then the use of the object > file is unrestricted, regardless of whether it is legally a derivative > work. (Executables containing this object code plus portions of the > Library will still fall under Section 6.) > > Otherwise, if the work is a derivative of the Library, you may > distribute the object code for the work under the terms of Section 6. > Any executables containing that work also fall under Section 6, > whether or not they are linked directly with the Library itself. > > 6. As an exception to the Sections above, you may also combine or > link a "work that uses the Library" with the Library to produce a > work containing portions of the Library, and distribute that work > under terms of your choice, provided that the terms permit > modification of the work for the customer's own use and reverse > engineering for debugging such modifications. > > You must give prominent notice with each copy of the work that the > Library is used in it and that the Library and its use are covered by > this License. You must supply a copy of this License. If the work > during execution displays copyright notices, you must include the > copyright notice for the Library among them, as well as a reference > directing the user to the copy of this License. Also, you must do one > of these things: > > a) Accompany the work with the complete corresponding > machine-readable source code for the Library including whatever > changes were used in the work (which must be distributed under > Sections 1 and 2 above); and, if the work is an executable linked > with the Library, with the complete machine-readable "work that > uses the Library", as object code and/or source code, so that the > user can modify the Library and then relink to produce a modified > executable containing the modified Library. (It is understood > that the user who changes the contents of definitions files in the > Library will not necessarily be able to recompile the application > to use the modified definitions.) > > b) Use a suitable shared library mechanism for linking with the > Library. A suitable mechanism is one that (1) uses at run time a > copy of the library already present on the user's computer system, > rather than copying library functions into the executable, and (2) > will operate properly with a modified version of the library, if > the user installs one, as long as the modified version is > interface-compatible with the version that the work was made with. > > c) Accompany the work with a written offer, valid for at > least three years, to give the same user the materials > specified in Subsection 6a, above, for a charge no more > than the cost of performing this distribution. > > d) If distribution of the work is made by offering access to copy > from a designated place, offer equivalent access to copy the above > specified materials from the same place. > > e) Verify that the user has already received a copy of these > materials or that you have already sent this user a copy. > > For an executable, the required form of the "work that uses the > Library" must include any data and utility programs needed for > reproducing the executable from it. However, as a special exception, > the materials to be distributed need not include anything that is > normally distributed (in either source or binary form) with the major > components (compiler, kernel, and so on) of the operating system on > which the executable runs, unless that component itself accompanies > the executable. > > It may happen that this requirement contradicts the license > restrictions of other proprietary libraries that do not normally > accompany the operating system. Such a contradiction means you cannot > use both them and the Library together in an executable that you > distribute. > > 7. You may place library facilities that are a work based on the > Library side-by-side in a single library together with other library > facilities not covered by this License, and distribute such a combined > library, provided that the separate distribution of the work based on > the Library and of the other library facilities is otherwise > permitted, and provided that you do these two things: > > a) Accompany the combined library with a copy of the same work > based on the Library, uncombined with any other library > facilities. This must be distributed under the terms of the > Sections above. > > b) Give prominent notice with the combined library of the fact > that part of it is a work based on the Library, and explaining > where to find the accompanying uncombined form of the same work. > > 8. You may not copy, modify, sublicense, link with, or distribute > the Library except as expressly provided under this License. Any > attempt otherwise to copy, modify, sublicense, link with, or > distribute the Library is void, and will automatically terminate your > rights under this License. However, parties who have received copies, > or rights, from you under this License will not have their licenses > terminated so long as such parties remain in full compliance. > > 9. You are not required to accept this License, since you have not > signed it. However, nothing else grants you permission to modify or > distribute the Library or its derivative works. These actions are > prohibited by law if you do not accept this License. Therefore, by > modifying or distributing the Library (or any work based on the > Library), you indicate your acceptance of this License to do so, and > all its terms and conditions for copying, distributing or modifying > the Library or works based on it. > > 10. Each time you redistribute the Library (or any work based on the > Library), the recipient automatically receives a license from the > original licensor to copy, distribute, link with or modify the Library > subject to these terms and conditions. You may not impose any further > restrictions on the recipients' exercise of the rights granted herein. > You are not responsible for enforcing compliance by third parties with > this License. > > 11. If, as a consequence of a court judgment or allegation of patent > infringement or for any other reason (not limited to patent issues), > conditions are imposed on you (whether by court order, agreement or > otherwise) that contradict the conditions of this License, they do not > excuse you from the conditions of this License. If you cannot > distribute so as to satisfy simultaneously your obligations under this > License and any other pertinent obligations, then as a consequence you > may not distribute the Library at all. For example, if a patent > license would not permit royalty-free redistribution of the Library by > all those who receive copies directly or indirectly through you, then > the only way you could satisfy both it and this License would be to > refrain entirely from distribution of the Library. > > If any portion of this section is held invalid or unenforceable under any > particular circumstance, the balance of the section is intended to apply, > and the section as a whole is intended to apply in other circumstances. > > It is not the purpose of this section to induce you to infringe any > patents or other property right claims or to contest validity of any > such claims; this section has the sole purpose of protecting the > integrity of the free software distribution system which is > implemented by public license practices. Many people have made > generous contributions to the wide range of software distributed > through that system in reliance on consistent application of that > system; it is up to the author/donor to decide if he or she is willing > to distribute software through any other system and a licensee cannot > impose that choice. > > This section is intended to make thoroughly clear what is believed to > be a consequence of the rest of this License. > > 12. If the distribution and/or use of the Library is restricted in > certain countries either by patents or by copyrighted interfaces, the > original copyright holder who places the Library under this License may add > an explicit geographical distribution limitation excluding those countries, > so that distribution is permitted only in or among countries not thus > excluded. In such case, this License incorporates the limitation as if > written in the body of this License. > > 13. The Free Software Foundation may publish revised and/or new > versions of the Lesser General Public License from time to time. > Such new versions will be similar in spirit to the present version, > but may differ in detail to address new problems or concerns. > > Each version is given a distinguishing version number. If the Library > specifies a version number of this License which applies to it and > "any later version", you have the option of following the terms and > conditions either of that version or of any later version published by > the Free Software Foundation. If the Library does not specify a > license version number, you may choose any version ever published by > the Free Software Foundation. > > 14. If you wish to incorporate parts of the Library into other free > programs whose distribution conditions are incompatible with these, > write to the author to ask for permission. For software which is > copyrighted by the Free Software Foundation, write to the Free > Software Foundation; we sometimes make exceptions for this. Our > decision will be guided by the two goals of preserving the free status > of all derivatives of our free software and of promoting the sharing > and reuse of software generally. > > NO WARRANTY > > 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO > WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. > EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR > OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY > KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE > IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE > LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME > THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. > > 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN > WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY > AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU > FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR > CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE > LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING > RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A > FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF > SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH > DAMAGES. > > END OF TERMS AND CONDITIONS > > How to Apply These Terms to Your New Libraries > > If you develop a new library, and you want it to be of the greatest > possible use to the public, we recommend making it free software that > everyone can redistribute and change. You can do so by permitting > redistribution under these terms (or, alternatively, under the terms of the > ordinary General Public License). > > To apply these terms, attach the following notices to the library. It is > safest to attach them to the start of each source file to most effectively > convey the exclusion of warranty; and each file should have at least the > "copyright" line and a pointer to where the full notice is found. > > > Copyright (C) > > This library is free software; you can redistribute it and/or > modify it under the terms of the GNU Lesser General Public > License as published by the Free Software Foundation; either > version 2.1 of the License, or (at your option) any later version. > > This library is distributed in the hope that it will be useful, > but WITHOUT ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > Lesser General Public License for more details. > > You should have received a copy of the GNU Lesser General Public > License along with this library; if not, write to the Free Software > Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > > Also add information on how to contact you by electronic and paper mail. > > You should also get your employer (if you work as a programmer) or your > school, if any, to sign a "copyright disclaimer" for the library, if > necessary. Here is a sample; alter the names: > > Yoyodyne, Inc., hereby disclaims all copyright interest in the > library `Frob' (a library for tweaking knobs) written by James Random Hacker. > > , 1 April 1990 > Ty Coon, President of Vice > > That's all there is to it! > ------------------------ end of proposed license ------------------ > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From gjhanna at gmail.com Sun Mar 11 14:21:17 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Mon, 12 Mar 2007 09:21:17 +1300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hi Pavel, We are using RXTX under VMWare server in production, quite satisfactorily. We're using Red Hat Enterprise Server 4, and ... Whatever the "enterprise" VMWare product is. Regards, Greg H > Subject: [Rxtx] RXTX under VMWare server > To: rxtx at qbang.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. [ ... snip ... ] -- Pavel Parkhomenko -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070311/4cebb6f9/attachment-0004.html From gergg at cox.net Sun Mar 11 23:39:19 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 12 Mar 2007 00:39:19 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: <45F4E787.6050502@cox.net> Trent Jarvi wrote: > I can start going through the method interfaces later this week and giving > feedback. I would suggest that the JSR should not be too generic in > nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel > drivers that intend to look like EIA232 ports at the kernel driver level. > > some ideas: > > EIA232PortInterface > TermiosInterface > SerialPortInterface > > Something that differentiates this from thing like USB, I2C, ... which > should not have to deal with legacy serial claiming to be the comm api. I'm going to throw out a suggestion, which I am mostly serious about. What would happen if we took the appropriate bits of the J2ME connector API, and just used that as the new COMM API so that finally JSE and JME had a common foundation for these kinds of things? Gregg Wonderly From ra85551 at gmail.com Mon Mar 12 09:08:37 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Mon, 12 Mar 2007 18:08:37 +0300 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Should any application use the modem, HyperTerminal won't be able to talk to the modem. But it actually can send and receive AT comands, while my application cannot :-( > Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Thansk for the reference. I examined that example and found that there's no significant differences between my read/write implementation and that one, except that SimpleSnuV1 listens for serialEvent's, but not for sake of data retrieval, just for printing them out - I don't know why ;-) > Note that modems could care less what OS is on top. If you are trying to > match new lines to the OS and sending it to the mode for AT commands, > thats probably a mistake. I do send strings to serial port, not to OS, and do try to get answers back. If it is the mistake, what's the right way? > Also it would not hurt to print out the > individual bytes that you are sending to make sure they did not get > mangled along the path. Yeah, I am printing these bytes before doing write, but it means that I only see what I intend to write. How can I ensure that these bytes have gone out of the box and reached my modem? BTW, I found that my send/receive method is complex enough, so I've rewritten it. Please, see the following code and point any mistakes, because I don't know where can they remain yet. private static final int LARGE_TIMEOUT = 15000; private static final int SMALL_TIMEOUT = 500; ... private String sendATCommand(String command, String waitFor, boolean isRegex, boolean isAddCRLF) throws BeaconConnectException { byte[] buffer = new byte[512]; int offset; String result = ""; try { if (waitFor != null) { serialPort.enableReceiveTimeout(LARGE_TIMEOUT); } else { serialPort.enableReceiveTimeout(SMALL_TIMEOUT); } if (command != null) { OutputStream serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } offset = 0; InputStream serialInput = serialPort.getInputStream(); while (serialInput.available() != -1) { int bytesRead = serialInput.read(buffer, offset, buffer.length - offset); if (bytesRead == 0) { break; } offset += bytesRead; result = new String(buffer, 0, offset).trim(); if (waitFor != null) { System.out.println(result); if (isRegex && result.matches(waitFor) || result.contains(waitFor)) { break; } } } } catch (UnsupportedCommOperationException e) { throw new MyException("unsupported operation"); } catch (IOException e) { throw new MytException("serial I/O error"); } return result; } -- Pavel Parkhomenko From clayno at hotpop.com Thu Mar 15 02:47:34 2007 From: clayno at hotpop.com (Christopher Layno) Date: Thu, 15 Mar 2007 16:47:34 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi, we're using the latest release of rxtx (2.1-7r2) for our system that has two applications using the library. one application sends requests to the modem while the other simply checks the modem status. we deployed our system on a pentium machine with red hat linux 9.0 installed. now the problem arises when these two applications try to access the same modem at the same time. one of them will eventually have to throw the PortInUseException as shown below: 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException gnu.io.PortInUseException: root PID = 743 Program = java root PID = 743 Program = java root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) this was expected. what we didn't expect though was that if we repeat the scenario 5 times, always 5 times, the application would also throw a VM error: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4473CD21 Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so Current Java thread: at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) - locked <0x44cfd4c8> (a gnu.io.CommPortIdentifier) at ************ at ************ - locked <0x4476a468> (a **********) at ************ at ************ at ************ at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java :261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages( TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run( TCPTransport.java:701) at java.lang.Thread.run(Thread.java:534) note: i replaced some sensitive data with asterisks our team has looked everywhere on the internet, including your mail archives, for a solution to this problem but to no avail. i really hope you could help us out on this one. thanks in advance! best regards, chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070315/1936460a/attachment-0004.html From tjarvi at qbang.org Fri Mar 16 04:30:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 04:30:25 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: On Thu, 15 Mar 2007, Christopher Layno wrote: > hi, > > we're using the latest release of rxtx (2.1-7r2) for our system that has two > applications using the library. one application sends requests to the modem > while the other simply checks the modem status. we deployed our system on a > pentium machine with red hat linux 9.0 installed. > > now the problem arises when these two applications try to access the same > modem at the same time. one of them will eventually have to throw the > PortInUseException as shown below: > > 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException > gnu.io.PortInUseException: root PID = 743 Program = java root PID = > 743 Program = java root PID = 743 Program = ??? root PID = 743 Program > = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root > PID = 743 Program = ??? root PID = 743 Program = ??? > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > > this was expected. what we didn't expect though was that if we repeat the > scenario 5 times, always 5 times, the application would also throw a VM > error: > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x4473CD21 > Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 > Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so > > Current Java thread: > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) Hi Chris The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. The code is originally by Werner Almesberger. He gave us permission to use it in rxtx. You might look at what has changed since 1998 in his fuser application. Or you can just do like other OSs and do the following in fuserImp.c JNIEXPORT jstring JNICALL Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv *env, jobject obj, jstring arg) { return (*env)->NewStringUTF(env, "Unknown Application"); } It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. -- Trent Jarvi tjarvi at qang.org From Adrien.TOS at ingenico.com Fri Mar 16 05:11:12 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Fri, 16 Mar 2007 12:11:12 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903CBC312@frsnprexc1.usr.ingenico.loc> Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070316/972ab214/attachment-0004.html From joachim at buechse.de Fri Mar 16 05:13:24 2007 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 16 Mar 2007 12:13:24 +0100 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. From tjarvi at qbang.org Fri Mar 16 16:36:29 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 16:36:29 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Fri Mar 16 16:02:23 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 16 Mar 2007 18:02:23 -0400 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Not all platforms are Unix based. Also mixing native library usage and command-line calls is not an elegant solution, IMHO. One or the other, but not both. Andre On 16-Mar-07, at 07:13 , Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is > trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We >> only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From clayno at hotpop.com Sun Mar 18 22:17:28 2007 From: clayno at hotpop.com (Christopher Layno) Date: Mon, 19 Mar 2007 12:17:28 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi everyone, thank you so much for your replies. they were really helpful. anyway, before i sent the email, my team was already implementing a temporary solution by using joachim's suggestion. we invoked a lsof command from our java code although i share the same concern with trent and andre-john about portability issues. that's why i said it's just temporary. my superiors have yet to approve our bug fix. so my question now is this: is recompiling the rxtx source code the only way to solve this problem? because if it's the only solution, then i think my superiors would rather have a new release from the rxtx community itself that fixes this bug(?) rather than have my team recompile the source code. best regards, chris Trent Jarvi wrote: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. ... It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070318/237463b2/attachment-0004.html From tjarvi at qbang.org Mon Mar 19 16:20:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Mar 2007 16:20:52 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: Hi Chris I can compile a new version after the 21st if you do not feel comfortable doing so. Please send me an email reminder off-line then. On Mon, 19 Mar 2007, Christopher Layno wrote: > hi everyone, > > thank you so much for your replies. they were really helpful. > > anyway, before i sent the email, my team was already implementing a > temporary solution by using joachim's suggestion. > we invoked a lsof command from our java code although i share the same > concern with trent and andre-john about > portability issues. that's why i said it's just temporary. my superiors have > yet to approve our bug fix. > > so my question now is this: is recompiling the rxtx source code the only way > to solve this problem? because if it's the only > solution, then i think my superiors would rather have a new release from the > rxtx community itself that fixes this bug(?) > rather than have my team recompile the source code. > > best regards, > > chris > > Trent Jarvi wrote: > > Hi Joachim > > It would be nice to have that functionality but calling the program > introduces too many issues imho. Explaining to someone why rxtx invoked a > rogue lsof does not sound very interesting. > > On Fri, 16 Mar 2007, Joachim Buechse wrote: > > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: > > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. > > _______________________________________________ > Rxtx mailing list > Rxtx 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 Eric.Arseneau at sun.com Tue Mar 20 11:47:33 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Tue, 20 Mar 2007 10:47:33 -0700 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 Message-ID: <46001E35.9040608@sun.com> Anyone have any experience with RXTX working with JDK 6 on other platforms ? From mm at UDel.Edu Tue Mar 20 12:18:29 2007 From: mm at UDel.Edu (Mike Markowski) Date: Tue, 20 Mar 2007 14:18:29 -0400 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 In-Reply-To: <46001E35.9040608@sun.com> References: <46001E35.9040608@sun.com> Message-ID: <46002575.4000306@udel.edu> Eric Arseneau wrote: > Anyone have any experience with RXTX working with JDK 6 on other platforms ? I'm using 32 bit intel, gentoo linux, jdk6 with no problems. My applications only use a serial port, though, nothing on the parallel port. Mike From falko.guderian at gmx.de Wed Mar 21 08:17:35 2007 From: falko.guderian at gmx.de (Falko Guderian) Date: Wed, 21 Mar 2007 15:17:35 +0100 Subject: [Rxtx] RXTX binaries for SH4 Message-ID: <46013E7F.40102@gmx.de> Dear developers, I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no possiblities to compile the source code. Better, I'm not able to do this at the moment. Can you provide me with rxtxSerial.dll (SH4) in the rxtx-2.1-8-testing version? (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) The reason for the testing version is I need custom baud rates. Thanks for help. Kind regards, Falko Guderian From tjarvi at qbang.org Wed Mar 21 21:38:37 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Mar 2007 21:38:37 -0600 (MDT) Subject: [Rxtx] RXTX binaries for SH4 In-Reply-To: <46013E7F.40102@gmx.de> References: <46013E7F.40102@gmx.de> Message-ID: On Wed, 21 Mar 2007, Falko Guderian wrote: > Dear developers, > > I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no > possiblities to compile the source code. Better, I'm not able to do this > at the moment. Can you provide me with rxtxSerial.dll (SH4) in the > rxtx-2.1-8-testing version? > (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) > > The reason for the testing version is I need custom baud rates. > > Thanks for help. > Hi Falko WinCE binary format is not supported by gcc. That makes compiling limited to those familiar with the WinCE tools. I hope someone is able to provide them for you but it is not likely. WinCE has been compiled by others in the past but rxtx.org builds have never included WinCE. There is some information with the source concerning WinCE builds if you decide to do it. We can share your results too if you like. The source in the WinCE has never been updated for the custom baud rate. That would need changes from the main source I presume. If you look at the source, you will note that Michal Hobot created a mini fork in the source to handle wince but it has not been updated for 3 years. -- Trent Jarvi tjarvi at qbang.org From Adrien.TOS at ingenico.com Thu Mar 22 07:08:55 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Thu, 22 Mar 2007 14:08:55 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Hi everybody, Do you have any comments on this issue? Thanks! AT ________________________________ De : Adrien TOS Envoy? : vendredi 16 mars 2007 12:11 ? : 'rxtx at qbang.org' Cc : Adrien TOS Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070322/2306c538/attachment-0004.html From jeremy.reeve at zen.co.uk Mon Mar 19 07:36:04 2007 From: jeremy.reeve at zen.co.uk (Jeremy S. Reeve) Date: Mon, 19 Mar 2007 13:36:04 +0000 Subject: [Rxtx] rxtx failing to compile on Fedora Core 6 Message-ID: <1174311364.21865.6.camel@d9thc> When trying to compile latest source : rxtx-2.1-7r2 I get the following when running configure: ---------------- checking os.version 2.6.18-1.2200.fc5smp WARNING: configure is having a hard time determining which directory contains the file jni_md.h. Edit Makefile and fix the variable JAVANATINC to point to the correct directory. The following options are available: /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/ /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/linux/ If there are more than one option available the first was selected. WARNING: Kernel include files do not match the current kernel configure: creating ./config.status ------------------------ which seems OK checking the resultant Makefile but when attempting to build with gmake install I get the following output : ---------------------- 34 problems (34 warnings)/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/javah -classpath .:/home/jsr/rxtxsrc/rxtx-2.1-7r2:/home/jsr/rxtxsrc/rxtx-2.1-7r2/src:/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/ext/RXTXcomm.jar -d i686-pc-linux-gnu -jni `(for i in CommDriver CommPortEnumerator CommPortIdentifier CommPort CommPortOwnershipListener Configure I2C I2CPortEvent I2CPortEventListener I2CPort LPRPort NoSuchPortException ParallelPortEvent ParallelPortEventListener ParallelPort PortInUseException Raw RawPortEvent RawPortEventListener RawPort RS485 RS485PortEvent RS485PortEventListener RS485Port RXTXCommDriver RXTXPort RXTXVersion SerialPortEvent SerialPortEventListener SerialPort UnsupportedCommOperationException UnSupportedLoggerException Zystem;do \ if grep > /dev/null native.* \( /home/jsr/rxtxsrc/rxtx-2.1-7r2/./src/$i.java; then \ echo gnu.io.$i; \ fi; \ done)` i686-pc-linux-gnu/gnu_io_CommPortIdentifier.h: No such file or directory make: *** [/home/jsr/rxtxsrc/rxtx-2.1-7r2/gnu/io/CommDriver.class] Error 1 ------------------------ Any ideas or pointers? Regards, Jeremy From tjarvi at qbang.org Sat Mar 24 08:12:54 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 Mar 2007 08:12:54 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > From Adrien.TOS at ingenico.com Sat Mar 24 11:53:22 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Sat, 24 Mar 2007 18:53:22 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> I do not have the threshold setting enabled, I have explicitely disabled it with: port_.disableReceiveThreshold(); I have also run the same tests with the threshold setting enabled, but they also fail in the same way as described below. So it seems there is a problem with timeout handling on Win32? ________________________________ From: rxtx-bounces at qbang.org on behalf of Trent Jarvi Sent: Sat 3/24/2007 3:12 PM To: RXTX Developers and Users Subject: Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 8312 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20070324/f9e39c9b/attachment-0004.bin From greg.johnson at manchester.ac.uk Sun Mar 25 13:41:36 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Sun, 25 Mar 2007 21:41:36 +0200 Subject: [Rxtx] Mac intel weirdness Message-ID: Hi folks, I'm trying to get rxtx to work on my macbook pro with a USB-serial dongle on it. I am using the 2.1-8 code from the CVS (though it seems to report itself as 2.1-7: makes it difficult to prove to oneself that the changes have 'taken'! - line 4210 in SerialImp.c, line 40 in RXTXVersion.java) I am trying the 2.1-8 because of horrible lock problems in 2.1-7. However, the serialport closure code seems to be broken - it won't close because it believes the (previously opened!) port doesn't exist. Here is what I'm trying: 0. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "false" 1. Open a port Serialport serialport = (SerialPort) commportidentifier.open ("test",100); 2. Talk to a device ... 3. Close port serialport.close(); 4. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "true" - why is this? 5. Try to reopen port Serialport serialport2 = (SerialPort) commportidentifier.open("test", 100); throws PortInUseException. I've dug around a bit in the source, and it seems the SerialPort.close () should call the CommPortIdentifier.internalClosePort() (line 67 of CommPort.java). However, I crash out with the NoSuchPortException when getPortIdentifier is called. Which seems quite weird to me, seeing as it is called on this - which was create just beforehand. Does anyone know how to fix this? Cheers, greg From knute at frazmtn.com Sat Mar 24 10:32:38 2007 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 24 Mar 2007 09:32:38 -0700 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc>, Message-ID: <4604F036.17833.135298@knute.frazmtn.com> > >The behavior of timeout depends upon the setting of the threshold. Do you >have the threshold setting? > This is the same bug I reported last fall. There was a fellow that sent me an email asking if it had been fixed. I told him I didn't think so. He got somebody to write a fix for him but I have not been able to contact him again for the actual changes. The inaccurate timeout and the failure of blocking when no timeouts are set is a serious bug in my humble opinion and renders the software unusable for my applications. I'd really like to have an alternative to the Sun comm api but there just isn't one that I know of. -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Mar 26 16:17:00 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 26 Mar 2007 16:17:00 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> Message-ID: >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. From ra85551 at gmail.com Tue Mar 27 10:18:36 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Tue, 27 Mar 2007 20:18:36 +0400 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Ultimately I found a solution. At first, that wasn't actually the VMWare + WinXP + RXTX issue, that was WinXP + RXTX issue. But on pure XP it sometimes workes, sometimes not, while under VMWare I had never seen my snippet working at all. SimpleSnuV1.java would not help me, because there is only one line I missed, and SimpleSnuV1.java also doesn't contain it! It is as follows: serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_OUT | SerialPort.FLOWCONTROL_RTSCTS_IN); Thank you for your attention. -- Pavel Parkhomenko From griff at op.pl Wed Mar 28 01:28:19 2007 From: griff at op.pl (griff@op.pl) Date: Wed, 28 Mar 2007 09:28:19 +0200 Subject: [Rxtx] No blocking read on Windows. Message-ID: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/5d07d571/attachment-0004.html -------------- next part -------------- Hi, I have problem that InputStram.read() (SerialPort)?returns -1 instead blocking and waiting for data. I found that this problem was ?known in 2005 : ? >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > >> Hi Trent >> >> Thanks for the fast response. >> Here's a Q&D test program for the blocking read on windows that just >> attempts to read one byte, and prints the resulting byte. On my system it >> returns -1, where I expect that it keeps waiting for data. >> >This isn't happening on Linux so the bug is in src/termios.c.? I'll have >something this weekend to fix that. I'm using RXTX 2.1.7r2 and the problem still is here. Im using Windows XP and java 1.5 disableReciveTimeout() and disableReciveTreshhold() dont help. ? best regards ? Piotr Zielniok From Adrien.TOS at ingenico.com Wed Mar 28 01:40:46 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Wed, 28 Mar 2007 09:40:46 +0200 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903E88880@frsnprexc1.usr.ingenico.loc> Looking at the code, it seems there is no support for infinite timeout? And maybe the count++ < 20 condition is breaking out of the loop too early? The only condition to break out of the loop should either be the timeout has expired or the number of requested bytes has been received. -----Message d'origine----- De : rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] De la part de Trent Jarvi Envoy? : mardi 27 mars 2007 00:17 ? : RXTX Developers and Users Objet : Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From j.kenneth.gentle at acm.org Wed Mar 28 06:44:15 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 28 Mar 2007 08:44:15 -0400 Subject: [Rxtx] No blocking read on Windows. In-Reply-To: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> References: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> Message-ID: <200703281844.l2SIiITW028614@qbang.org> Just another "ME TOO!" - I'm seeing this problem on Windows XP, jre for windows XP/Embedded. I cranked receiveTimeout up to Integer.MAX_INT, but it doesn't seem to wait that long At 03:28 2007-03-28, you wrote: >Hi, >I have problem that InputStram.read() (SerialPort) returns -1 >instead blocking and waiting for data. I found that this problem >was known in 2005 : > > >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > > > >> Hi Trent > >> > >> Thanks for the fast response. > >> Here's a Q&D test program for the blocking read on windows that just > >> attempts to read one byte, and prints the resulting byte. On my system it > >> returns -1, where I expect that it keeps waiting for data. > >> > > >This isn't happening on Linux so the bug is in src/termios.c. I'll have > >something this weekend to fix that. > >I'm using RXTX 2.1.7r2 and the problem still is here. >Im using Windows XP and java 1.5 >disableReciveTimeout() and disableReciveTreshhold() dont help. > >best regards > >Piotr Zielniok > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From greg.johnson at manchester.ac.uk Wed Mar 28 14:43:29 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Wed, 28 Mar 2007 22:43:29 +0200 Subject: [Rxtx] Cannot close and reopen serial port Message-ID: <377F9765-7A9D-4CE9-9176-FFB63A2594F0@manchester.ac.uk> Dear all, It appears I cannot close a port properly: SerialPort serialport = portid.open("myprog",100); // do some stuff, all works fine serialport.close(); // all seems fine but... SerialPort sp2 = portid.open("myprog",100); throws PortInUseException. And when I dig into the rxtx code, I find in CommPort.java, in close(): CommPortIdentifier cp = CommPortIdentifier.getPortIdentifier(this); (line 64 or there abouts) but this throws a NoSuchPortException which is caught but ignored (line 74ish). Can anyone suggest how this could happen: a port that was valid, opened, and used, throws a NSPE when it comes to closing it? I'm pulling my (remaining) hair out over this one! Cheers, greg PS And thanks for RXTX - it's great to have! PPS (21.-7. winxp/osx both, java 1.5) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/c28852fc/attachment-0004.html From rxtx at vrijheidslaan.net Fri Mar 30 16:52:50 2007 From: rxtx at vrijheidslaan.net (Rob) Date: Fri, 30 Mar 2007 22:52:50 -0000 Subject: [Rxtx] Cvs Question Message-ID: <61896.80.126.150.87.1175295162.squirrel@webmail.provalue.nl> Hi There, Im trying to get the latest version to work on mac osx. Problem is that i can't checkout version 2.1.8. Probably my fault but can some one please give me the alternative commands for: [user at myhost]$ export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot [user at myhost]$ cvs login Thanx, Rob From ra85551 at gmail.com Thu Mar 1 03:47:06 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Thu, 1 Mar 2007 13:47:06 +0300 Subject: [Rxtx] enableReceiveTimeout() issue Message-ID: Hello, world! I found a limitation of 16300 ms for CommPort's enableReceiveTimeout() method, while in original javax.comm docs there are no any references to that. Is that a bug or feature? I actually need longer timeouts sometimees. -- Pavel Parkhomenko From lyon at docjava.com Thu Mar 1 07:54:17 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 01 Mar 2007 09:54:17 -0500 Subject: [Rxtx] parametric singleton design pattern In-Reply-To: References: <22d55aea0702081207q5e7f6785l352d498d6f5f9fb1@mail.gmail.com> <22d55aea0702100034o3bcf42f3j1d1a6257029a67b0@mail.gmail.com> Message-ID: Hi All, I have been thinking about the use of a design pattern to cache resources that are consumed by processes. Toward that end, I have arrived at a parametric singleton design pattern, which I mentioned on this list some time ago. The idea has been published at: http://www.jot.fm/issues/issue_2007_03/column2 I can't help but think that there should be an API available for dealing with the tracking of serial port usage. Perhaps it is a kind of resource manager called the: SerialPortManager basic prototypes already exist in this vain. See, for example: http://www.ce.rit.edu/research/projects/2005_fall/rt_poolsystem/doc/PoolMon/SerialPortManager.html http://www.eventhelix.com/RealtimeMantra/PatternCatalog/serial_port_design_pattern.htm And others shown by a google search on "SerialPortManager" Cheers! - Doug From Eric.Arseneau at sun.com Thu Mar 1 10:15:03 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:15:03 -0800 Subject: [Rxtx] Any known Java 6 issues with RXTX 2.1-7r2 ? Message-ID: <45E70A17.1060206@sun.com> I just did a test on a recent build of Solaris 11 x86 and it seems that I can connect to my serial device fine when Java 5 is the default, but when Java 6 is the default, no go. Any information ? From Eric.Arseneau at sun.com Thu Mar 1 10:19:58 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:19:58 -0800 Subject: [Rxtx] Mac OS X and missing data Message-ID: <45E70B3E.7040908@sun.com> We have a device which is USB based but presents itself as a serial port to a machine. On my MacBook Pro I can get excellent throughput if I get my device to send data as quickly as possible. On the desktop side, if I do an type of disk IO to log the data I get, I end up with some missing data at some point. I hooked up a USB analyzer and did confirm that all the data is sent as expected to the desktop from the device. I found a work around for this, buffer the data in memory and only write the data out when I've received it all. However, when the same code and same device is attempted on a co-workers MacBook Pro (same hardware specs), I get errors and must slow down dramatically the device side's sending of data. Any ideas/recommendations on what I can do to get rid of this error ? From what I can tell, it seems that RXTX is not able to wake up to the interrupts coming in indicating data is ready, quickly enough, is there anything I can do ? From chinkaiw at hotmail.com Fri Mar 2 00:57:43 2007 From: chinkaiw at hotmail.com (Wang Chinkai) Date: Fri, 02 Mar 2007 07:57:43 +0000 Subject: [Rxtx] dynamic detect rs232 port Message-ID: Hi all I have a question about detecting rs232 port dynamicly. I have to aceess some port and detect rs232 port at the same time. Some usb device simulates rs232 port , and I can not know what the port name it gets until it connects,so I have to detect it dynamic,but I have to access another rs232 device at the same time. I found a problem. If I use CommPortIdentifier.getPortIdentifiers() to get new port list , and the other rs232 access function will not close port correctly. So , How can I solve it . Thanks. _________________________________________________________________ ?? 2GB ???? Windows Live Mail ????????????? http://ideas.live.com/programpage.aspx?versionid=5d21c51a-b161-4314-9b0e-4911fb2b2e6d From eu259473 at tele2.it Fri Mar 2 06:16:40 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 02 Mar 2007 14:16:40 +0100 Subject: [Rxtx] rxtx on HP tru 64 unix Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070302/706c7a70/attachment-0005.html From tjarvi at qbang.org Fri Mar 2 08:39:33 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 08:39:33 -0700 (MST) Subject: [Rxtx] rxtx on HP tru 64 unix In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, "Giuseppe Marchese" wrote: > Hi > > I try to install rxtx on hp tru 64 but make fails, > There are somebody that do the same and work. > > > Sorry for may english! > > Hi Giuseppe Could you provide a log of the failure? script ./configure make # use gnu make exit The information will be in the typescript created. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 2 19:56:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 19:56:52 -0700 (MST) Subject: [Rxtx] dynamic detect rs232 port In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, Wang Chinkai wrote: > Hi all > > I have a question about detecting rs232 port dynamicly. > > I have to aceess some port and detect rs232 port at the same time. > Some usb device simulates rs232 port , and I can not know > what the port name it gets until it connects,so I have to detect it > dynamic,but I have to access > another rs232 device at the same time. > > I found a problem. Hi Wang This is a known problem. The code is braindead there. In fact there needs to be events even in a rudamentary way when you add a usb dongle. I'm burried in tasks not far from rxtx but not in rxtx. I can't get to the problem but we would accept patches if you dig into it. [I'm getting to the license question earlier too; I don't have another 10%] -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Fri Mar 2 23:19:01 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 01:19:01 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Hi, Under ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable USB -> serial converter(using virtual com port drivers), with using example code pretty much straight out of http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port opens fine, enumerations all work, etc. My application calls for a large amount of data to be transferred in a short amount of time at 2,000,000 baud. My hardware sends approximately 15,232 bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL converter work fine, and the application works using C++. In C++, I do a hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); to open the port, and a boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); to read the port. The variable buffer fills with the 15238 bytes, and returns. If I do a resultz = is.read(cbuf,0,15238); in java with RXTX where is = new BufferedReader(new InputStreamReader(port.getInputStream())); and where resultz is an int, and cbuf is a char [] cbuf, resultz gets EXACTLY 3968 bytes the first time called. If I call it multiple times, I get roughly 11k total(less than what is sent), never more than the 3968 bytes per is.read() call. My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 bytes. I've played with inputbuffersize, receive threshold, receivetimeout, and so on. The FTDI virtual com port drivers that I'm using are rock solid, and have had zero problems with them using a variety of applications, some of my own, some professionally written, etc. No flow control is used anyplace, no RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. No exceptions are being thrown. What am I doing wrong, and what I can adjust to receive the full 15k bytes in one single read? Thanks! Keith From Eric.Arseneau at sun.com Fri Mar 2 23:32:07 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Fri, 02 Mar 2007 22:32:07 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <45E91667.20501@sun.com> This is the same type of thing that is happening to me on Mac OS X and does not seem to behave the same on different machines. I posted a day or two ago on this with subject "Mac OS X and missing data". Would love to hear if there is a solution to this :) From tjarvi at qbang.org Sat Mar 3 10:54:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 10:54:17 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > Hi, > > Under > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable > USB -> serial converter(using virtual com port drivers), with using example > code pretty much straight out of > http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port > opens fine, enumerations all work, etc. > > My application calls for a large amount of data to be transferred in a short > amount of time at 2,000,000 baud. My hardware sends approximately 15,232 > bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL > converter work fine, and the application works using C++. > > In C++, I do a > > hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, > OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); > > to open the port, and a > > boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); > > to read the port. > > The variable buffer fills with the 15238 bytes, and returns. > > If I do a > > resultz = is.read(cbuf,0,15238); in java with RXTX > > where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > > and where resultz is an int, and cbuf is a char [] cbuf, resultz gets > EXACTLY 3968 bytes the first time called. If I call it multiple times, I get > roughly 11k total(less than what is sent), never more than the 3968 bytes > per is.read() call. > > My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 > bytes. > > I've played with inputbuffersize, receive threshold, receivetimeout, and so > on. The FTDI virtual com port drivers that I'm using are rock solid, and > have had zero problems with them using a variety of applications, some of my > own, some professionally written, etc. No flow control is used anyplace, no > RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. > > No exceptions are being thrown. > > What am I doing wrong, and what I can adjust to receive the full 15k bytes > in one single read? > > Thanks! > Hi Keith I would expect a 20 meg application is going to have different behavior with the OS than a smaller application with respect to the kernel memory managment, schedualing, ... Something subtle could be causing problems. With respect to the recieve timeout and threshold, if you set the timeout to zero and the threshold to the size of data you expect, read should not return until it get that data. You may try with a stand alone application that tests just that with the C/C++ API. If the read is returning with less data when tested for short reads, you have found a bug in the device driver more than likely. The USB dongle vendor would probably be interested in knowing about this. As mentioned, these devices are getting very good; almost bug free. I suspect you found a bug though if you did use the threshold and timeout properly. The missing data is typical when not using flow control. When the OS buffering fills, the hardware will start dropping bytes. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:38:52 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:38:52 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> update: I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now instead of 3968. This makes sense. 128 bytes of overhead + 3968 bytes of data = 4096 transfer size 32 bytes of overhead + 992 bytes of data = 1024 transfer size. 1/4 the data = 1/4 the overhead. I rearranged my reading like so: resultz = is.read(cbuf,0,3968); resultz = is.read(cbuf,3968,3968); resultz = is.read(cbuf,7936,3968); while (!(is.ready())); // wait for ready resultz = is.read(cbuf,11904,3334); and this grabs 15,238 bytes total. BUT, I still have the quandry of the screwed up multi-bytes. I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. Approx 8% of the data. The bad bytes always seem to take the flavor of 0x2018, 0x2019, x2022, x2030, x201d. Are these maybe errors and I don't know what they enumerate to? I still can't believe some other layer isn't handling putting those bytes together all in one stream for me. Thanks Keith ----- Original Message ----- From: "Keith" To: "Bob Jacobsen" ; "RXTX Developers and Users" Sent: Saturday, March 03, 2007 11:26 AM Subject: Re: [Rxtx] is.read() only returning 3968 bytes > Bob, > > > Interesting numerical coincidence is that (max USB transfer) - (what > > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > > needed to transfer that much data. > > I was thinking along the same lines. I don't know USB well, but I do know > that those numbers were close enough to warrant investigating the > relationship between them. > > > I think what you're seeing is the internal buffering of the USB data > > stream. You'll need some form of higher-level buffering to smooth > > that out. > > Shouldn't the InputStreamReader() and BufferedReader() provide this type of > buffering? Isn't that the idea behind those? > > > All hypotheses need to be tested. In this case, a test would be to > > check for missing data. If this idea is right, you'll get _all_ the > > data, but you won't be missing characters. > > I did start looking at the data. -- I'm getting weird results. > > I tried this: > > loopzz = 0; > > for (looptwo = 0; looptwo < 100000; looptwo++) { > while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > > }} > > So I'm reading one character at a time. The good news is that loopzz is > exactly 15238 at the end of the routine, which is perfectly correct. I > picked looptwo value out of thin air. > > The weird results come in terms of the values, the data isn't correct at > least in one case. Look here: > > 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > > This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). > But the 0x89 was replaced by 0x2030. Why the heck would the returned value > be 0x2030?? Why is the returned byte completely out of range? Why the > multibyte return? > > From InputStream in the API: > > read > public abstract int read() > throws IOExceptionReads the next byte of data from the > input stream. The value byte is returned as an int in the range 0 to 255. If > no byte is available because the end of the stream has been reached, the > value -1 is returned. This method blocks until input data is available, the > end of the stream is detected, or an exception is thrown. > Value should be 0-255. > > > In my application time is really critical, reading 1 byte at a time is > probably not going to work. > > Thanks Eric & Bob for looking at this. > > Keith > From tjarvi at qbang.org Sat Mar 3 12:52:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 12:52:27 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > update: > > I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now > instead of 3968. > > This makes sense. > > 128 bytes of overhead + 3968 bytes of data = 4096 transfer size > 32 bytes of overhead + 992 bytes of data = 1024 transfer size. > > 1/4 the data = 1/4 the overhead. > > I rearranged my reading like so: > > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. > Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? > > I still can't believe some other layer isn't handling putting those bytes > together all in one stream for me. > The layer for this in Serial land is flow control. Software and hardware flow control prevent the overruns you observe. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:54:41 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:54:41 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <001a01c75dcd$c8802a70$6600a8c0@jbh757ktruws7g> Trent, Thanks for taking the time to reply. > I would expect a 20 meg application is going to have different behavior > with the OS than a smaller application with respect to the kernel memory > managment, schedualing, ... Something subtle could be causing problems. Well, at least I know the VCP drivers, the OS, etc can handle 2mbps reliably. Without hiccuping or dropping bytes. The C++ code works reliably without flow control. > The missing data is typical when not using flow control. When the OS > buffering fills, the hardware will start dropping bytes. I'm actually not getting MISSING data, I'm getting CORRUPTED data. If you look at my most recent post, I'm getting these bad bytes in place of the correct values: 0x2018, 0x2019, x2022, x2030, x201d. Why would is.read() return values not in the range of 0-255 ? Thanks. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 08:59:14 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 07:59:14 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: At 1:19 AM -0500 3/3/07, Keith wrote: >If I do a > >resultz = is.read(cbuf,0,15238); in java with RXTX > >where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > >and where resultz is an int, and cbuf is a char [] cbuf, resultz gets >EXACTLY 3968 bytes the first time called. If I call it multiple times, I get >roughly 11k total(less than what is sent), never more than the 3968 bytes >per is.read() call. > >My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 >bytes. Interesting numerical coincidence is that (max USB transfer) - (what you get) = 4096-3968 = 128 bytes is (almost) the size of the headers needed to transfer that much data. I think what you're seeing is the internal buffering of the USB data stream. You'll need some form of higher-level buffering to smooth that out. All hypotheses need to be tested. In this case, a test would be to check for missing data. If this idea is right, you'll get _all_ the data, but you won't be missing characters. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 09:26:14 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 11:26:14 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Bob, > Interesting numerical coincidence is that (max USB transfer) - (what > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > needed to transfer that much data. I was thinking along the same lines. I don't know USB well, but I do know that those numbers were close enough to warrant investigating the relationship between them. > I think what you're seeing is the internal buffering of the USB data > stream. You'll need some form of higher-level buffering to smooth > that out. Shouldn't the InputStreamReader() and BufferedReader() provide this type of buffering? Isn't that the idea behind those? > All hypotheses need to be tested. In this case, a test would be to > check for missing data. If this idea is right, you'll get _all_ the > data, but you won't be missing characters. I did start looking at the data. -- I'm getting weird results. I tried this: loopzz = 0; for (looptwo = 0; looptwo < 100000; looptwo++) { while (is.ready()) { cbuf[loopzz] = (char) is.read(); loopzz++; }} So I'm reading one character at a time. The good news is that loopzz is exactly 15238 at the end of the routine, which is perfectly correct. I picked looptwo value out of thin air. The weird results come in terms of the values, the data isn't correct at least in one case. Look here: 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). But the 0x89 was replaced by 0x2030. Why the heck would the returned value be 0x2030?? Why is the returned byte completely out of range? Why the multibyte return? >From InputStream in the API: read public abstract int read() throws IOExceptionReads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown. Value should be 0-255. In my application time is really critical, reading 1 byte at a time is probably not going to work. Thanks Eric & Bob for looking at this. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 14:44:50 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 13:44:50 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: Java's "char" type is Unicode. I think what you're seeing is a bug in the byte -> Unicode translation. 0x2018, 0x2019 are the curly open and close quotes. There used to be (and might still be) bugs in the conversion of these in a couple of libc versions. Some of the ASCII -> ISO and ISO -> ASCII routines were a little over-ambitious with respect to handling the open and close quotes, and tried to convert them to the "curly" form inappropriately. Try _not_ casting it to char. Bob At 11:26 AM -0500 3/3/07, Keith wrote: >Bob, > >> Interesting numerical coincidence is that (max USB transfer) - (what >> you get) = 4096-3968 = 128 bytes is (almost) the size of the headers >> needed to transfer that much data. > >I was thinking along the same lines. I don't know USB well, but I do know >that those numbers were close enough to warrant investigating the >relationship between them. > >> I think what you're seeing is the internal buffering of the USB data >> stream. You'll need some form of higher-level buffering to smooth >> that out. > >Shouldn't the InputStreamReader() and BufferedReader() provide this type of >buffering? Isn't that the idea behind those? > >> All hypotheses need to be tested. In this case, a test would be to >> check for missing data. If this idea is right, you'll get _all_ the >> data, but you won't be missing characters. > >I did start looking at the data. -- I'm getting weird results. > >I tried this: > >loopzz = 0; > >for (looptwo = 0; looptwo < 100000; looptwo++) { >while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > >}} > >So I'm reading one character at a time. The good news is that loopzz is >exactly 15238 at the end of the routine, which is perfectly correct. I >picked looptwo value out of thin air. > >The weird results come in terms of the values, the data isn't correct at >least in one case. Look here: > >0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > >This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). >But the 0x89 was replaced by 0x2030. Why the heck would the returned value >be 0x2030?? Why is the returned byte completely out of range? Why the >multibyte return? > >>From InputStream in the API: > >read >public abstract int read() > throws IOExceptionReads the next byte of data from the >input stream. The value byte is returned as an int in the range 0 to 255. If >no byte is available because the end of the stream has been reached, the >value -1 is returned. This method blocks until input data is available, the >end of the stream is detected, or an exception is thrown. >Value should be 0-255. > > >In my application time is really critical, reading 1 byte at a time is >probably not going to work. > >Thanks Eric & Bob for looking at this. > >Keith > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 15:10:11 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 17:10:11 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Bob said ..... > Java's "char" type is Unicode. I think what you're seeing is a bug > in the byte -> Unicode translation. Bob -- I think you hit the nail on the head. I was just coming to the same realization here. I knew that something funny was going on because the same bytes always got "corrupted." I'm pretty sure its in the InputStreamReader() functionality where the conversion junk is happening. Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. I don't know if simply changing the cast is going to work. Since the conversion is happening upstream (pun intended), I don't think my cast is doing this. Also I think the compiler forced me to use the cast. I'm still playing around, and I'll report back once I nail it down. Thanks!! Keith From tjarvi at qbang.org Sat Mar 3 15:59:46 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 15:59:46 -0700 (MST) Subject: [Rxtx] Win64 rxtx Testers? Message-ID: I have compiled win64 binaries of rxtx. Are there any users interested in testing them? If so, I'll look into putting them on the web site. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Mar 3 15:35:06 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 14:35:06 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: Because of this and similar problems, JMRI does all it's serial IO using +only+ byte values. It's a but of a pain, as Java wants to go to char and int types a little too aggressively, but it does solve the "uncontrolled conversions" problems. Bob At 5:10 PM -0500 3/3/07, Keith wrote: >Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > >Bob -- I think you hit the nail on the head. > >I was just coming to the same realization here. I knew that something funny >was going on because the same bytes always got "corrupted." > >I'm pretty sure its in the InputStreamReader() functionality where the >conversion junk is happening. > >Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > >I don't know if simply changing the cast is going to work. Since the >conversion is happening upstream (pun intended), I don't think my cast is >doing this. Also I think the compiler forced me to use the cast. -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mark at mdsh.com Sun Mar 4 11:01:33 2007 From: mark at mdsh.com (Mark Himsley) Date: Sun, 04 Mar 2007 18:01:33 +0000 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: <5C01AC72C200388815C04982@bedroom.mdsh.local> On 03 March 2007 14:38 -0500 Keith wrote: > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT > consistent. Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? It looks like you need to use DataInputStream and DataOutputStream. -- Mark Himsley From tjarvi at qbang.org Sun Mar 4 11:35:08 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 11:35:08 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" > > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > > * Line #21 - Not sure if you need a (TM) mark for > the term "Sun" > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > OK. I'm going through this today. Some groups ask if rxtx could be under their license also. I think this is a good example of why I resist multiple licenses and focus on why the current license may not be usable by them. The RXTX project is a convergence of hobby and commercial interests. I happen to do both right now. The problem with licensing is we have to stay on top of them as they change. Clearly, adding more licenses will not make this easier. I'm acting as the hobby person today. RXTX always favors the hobby people. But as we move forward, I'm going to need to bring this to lawyers at work and explain to them what is going on. Others here may have to do this also. I don't anticipate problems or unexpected changes. The goal is a consistant, comprehendable and usable license as close to what we have now as possible. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 14:52:10 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 14:52:10 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (1/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: I'm breaking this into two parts. I expect the second part will need more attention. Comments first, then the changed material below. On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > Thanks > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. OK. RXTX for consitent use. java should not be capitalized because it does not only mean Sun [TM] Java [TM]. An example of this not meaning Java is when people use RXTX with GCJ. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". There are not any contributors that are in all of RXTX yet but I did update the comment to try to reflect the current situation without making it a nightmare to maintain. I looked to see how the Linux kernel does it as a reference point. > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" The URL can be problematic. I have done so below with a time reference. GNU does not provide version information in their URLS. I picture this being a problem when the version 3 comes out. > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > This will be corrected when the copy is updated to the version linked below. ---------------- begin proposed material involved -------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. ----------------- end proposed material involved -------------------- I'll be looking at the linking issue again next. That should be all that remains other than including the 2.1 version. Let me know if you have problems with anything here. I do not want to dilute the material I post next with these housekeeping tasks. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 16:08:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 16:08:36 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: For those that are wondering what is going on here, this next bit is the meat of the changes. We agreed a long time ago to put this disclaimer in. We did a so so job. It was in rxtx 2.0, not well written, ... So some groups using rxtx that would like to ship rxtx so users don't need to download, install, go to the mail-list to find why it failed, ... Then their legal teams tell them section 5 paragraph 2 is a show stopper. That was never the intent. Now going through what remains... > and might need a (TM) suffix to make Sun happy. Added disclaimer at the ended 'all trademarks belong...' > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. OK. As you can see I was trying to adjust GNU text there for the LGPL. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. used dynamically linked terminology. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". I tried to address this more upfront with an intent statement. Let me know if you have problems with it. I also tried to make it a little more clear what was derived from the GNU solution by moving the link location closer to GNU's suggestion. > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > Thats the intent. Here is the combined fixes. Note that only the material in /*-- --*/ is being touched. The new GPL license is there but unmodified. ------------------------ begin proposed new license ------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. | | An executable that contains no derivative of any portion of RXTX, but | is designed to work with RXTX by being dynamically linked with it, | is considered a "work that uses the Library" subject to the terms and | conditions of the GNU Lesser General Public License. | | The following has been added to the RXTX License to remove | any confusion about linking to RXTX. We want to allow in part what | section 5, paragraph 2 of the LGPL does not permit in the special | case of linking over a controlled interface. The intent is to add a | Java Specification Request or standards body defined interface in the | future as another exception but one is not currently available. | | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface | | As a special exception, the copyright holders of RXTX give you | permission to link RXTX with independent modules that communicate with | RXTX solely through the Sun Microsytems CommAPI interface version 2, | regardless of the license terms of these independent modules, and to copy | and distribute the resulting combined work under terms of your choice, | provided that every copy of the combined work is accompanied by a complete | copy of the source code of RXTX (the version of RXTX used to produce the | combined work), being distributed under the terms of the GNU Lesser General | Public License plus this exception. An independent module is a | module which is not derived from or based on RXTX. | | Note that people who make modified versions of RXTX are not obligated | to grant this special exception for their modified versions; it is | their choice whether to do so. The GNU Lesser General Public License | gives permission to release a modified version without this exception; this | exception also makes it possible to release a modified version which | carries forward this exception. | | You should have received a copy of the GNU Lesser General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA | All trademarks belong to their respective owners. --------------------------------------------------------------------------*/ The original GNU Lesser General Public License Follows. GNU LESSER GENERAL PUBLIC LICENSE Version 2.1, February 1999 Copyright (C) 1991, 1999 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. [This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence the version number 2.1.] Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This license, the Lesser General Public License, applies to some specially designated software packages--typically libraries--of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below. When we speak of free software, we are referring to freedom of use, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish); that you receive source code or can get it if you want it; that you can change the software and use pieces of it in new free programs; and that you are informed that you can do these things. To protect your rights, we need to make restrictions that forbid distributors to deny you these rights or to ask you to surrender these rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library or if you modify it. For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights. We protect your rights with a two-step method: (1) we copyright the library, and (2) we offer you this license, which gives you legal permission to copy, distribute and/or modify the library. To protect each distributor, we want to make it very clear that there is no warranty for the free library. Also, if the library is modified by someone else and passed on, the recipients should know that what they have is not the original version, so that the original author's reputation will not be affected by problems that might be introduced by others. Finally, software patents pose a constant threat to the existence of any free program. We wish to make sure that a company cannot effectively restrict the users of a free program by obtaining a restrictive license from a patent holder. Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license. Most GNU software, including some libraries, is covered by the ordinary GNU General Public License. This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs. When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library. We call this license the "Lesser" General Public License because it does Less to protect the user's freedom than the ordinary General Public License. It also provides other free software developers Less of an advantage over competing non-free programs. These disadvantages are the reason we use the ordinary General Public License for many libraries. However, the Lesser license provides advantages in certain special circumstances. For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License. In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software. For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU operating system, as well as its variant, the GNU/Linux operating system. Although the Lesser General Public License is Less protective of the users' freedom, it does ensure that the user of a program that is linked with the Library has the freedom and the wherewithal to run that program using a modified version of the Library. The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, whereas the latter must be combined with the library in order to run. GNU LESSER GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License Agreement applies to any software library or other program which contains a notice placed by the copyright holder or other authorized party saying it may be distributed under the terms of this Lesser General Public License (also called "this License"). Each licensee is addressed as "you". A "library" means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables. The "Library", below, refers to any such software library or work which has been distributed under these terms. A "work based on the Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term "modification".) "Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library. Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does. 1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) The modified work must itself be a software library. b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change. c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License. d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful. (For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library. In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. 4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange. If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code. 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables. When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law. If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.) Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself. 6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications. You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things: a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.) b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. c) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution. d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place. e) Verify that the user has already received a copy of these materials or that you have already sent this user a copy. For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute. 7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things: a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above. b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work. 8. You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 9. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Library (or any work based on the Library), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Library or works based on it. 10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties with this License. 11. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply, and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 12. If the distribution and/or use of the Library is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Library under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 13. The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation. 14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Libraries If you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the ordinary General Public License). To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Also add information on how to contact you by electronic and paper mail. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the library, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the library `Frob' (a library for tweaking knobs) written by James Random Hacker. , 1 April 1990 Ty Coon, President of Vice That's all there is to it! ------------------------ end of proposed license ------------------ -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sun Mar 4 16:26:04 2007 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 04 Mar 2007 17:26:04 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <45EB558C.3010609@cox.net> Bob Jacobsen wrote: > Because of this and similar problems, JMRI does all it's serial IO > using +only+ byte values. It's a but of a pain, as Java wants to go > to char and int types a little too aggressively, but it does solve > the "uncontrolled conversions" problems. Anytime that you are reading bytes of data that is not printable, unicode text, in Java, you really need to stay away from the Readers. Use input stream only, or you will see unicode valued byte groups converted to unicode "char" values. Gregg Wonderly From joachim at buechse.de Mon Mar 5 04:23:48 2007 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 5 Mar 2007 12:23:48 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> The behaviour is exactly what you asked for in you code. is = new BufferedReader(new InputStreamReader(port.getInputStream())); Readers return Text (ie unicode chars) not bytes. You instantiate the InputStreamReader without saying which charset you want, which means "platform default". As this is on Windows, it will convert Windows characters to equivalent unicode characters. If you want to read bytes, read bytes not Text. Reading bytes is done with InputStream and BufferedInputStream. BTW: The InputStream and Reader methods that read arrays are not guarenteed to fill up the array. You always have to check what you really got, and advance your index accordingly. A typical "read up to 32k" method looks like this: InputStream is= ... // -- determine the max buffer size int len= is.available(); if (len == 0) { len= 32 * 1024; } // -- read all available data byte[] buffer= new byte[len]; int pos= 0; int read; do { read= is.read(buffer, pos, buffer.length - pos); pos= pos + read; } while (read != -1 && pos < buffer.length); Best regards, Joachim --- Joachim B?chse Phone: +41 44 500 2604 Buechse Consulting Hadlaubsteig 2 CH-8006 Z?rich On 03.03.2007, at 23:10, Keith wrote: > Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > > Bob -- I think you hit the nail on the head. > > I was just coming to the same realization here. I knew that > something funny > was going on because the same bytes always got "corrupted." > > I'm pretty sure its in the InputStreamReader() functionality where the > conversion junk is happening. > > Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > > I don't know if simply changing the cast is going to work. Since the > conversion is happening upstream (pun intended), I don't think my > cast is > doing this. Also I think the compiler forced me to use the cast. > > I'm still playing around, and I'll report back once I nail it down. > > Thanks!! > > Keith > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Mon Mar 5 07:25:46 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 05 Mar 2007 08:25:46 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> Message-ID: <45EC286A.8060608@cox.net> Joachim Buechse wrote: > BTW: The InputStream and Reader methods that read arrays are not > guarenteed to fill up the array. You always have to check what you > really got, and advance your index accordingly. A typical "read up to > 32k" method looks like this: > > InputStream is= ... > // -- determine the max buffer size > int len= is.available(); > if (len == 0) { > len= 32 * 1024; > } > // -- read all available data > byte[] buffer= new byte[len]; > int pos= 0; > int read; > do { > read= is.read(buffer, pos, buffer.length - pos); > pos= pos + read; > } while (read != -1 && pos < buffer.length); > My preferred structure is. byte arr[ len ]; int cnt; int off = 0; while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { off += cnt; } This keeps you from adding -1 to pos when the read returns -1. It also skips out when the read is 0 bytes which, is not a described EOF in InputStream java docs, but is a condition I want to be aware of. Gregg Wonderly From joachim at buechse.de Tue Mar 6 02:52:58 2007 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 6 Mar 2007 10:52:58 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <45EC286A.8060608@cox.net> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: The code I copied was from a file resource reader, it shouldn't really be applied to networking/external IO code. Mea culpa. However aborting when you get 0 from read is not always what you want either (you kind of indicated that already). Some unix java implementations will return 0 if the kernel read was aborted with EINTER, which is rarely the point where you want to abort your read - at least not without further checks. A "complete" solution always depends on the events you need to handle and the time the total read could take in reality. In some cases it's worth checking Thread.isInterrupted() in the loop, some code re-loops on 0 but only a limited number of times, some check a total timeout limit, etc... Best regards, Joachim On 05.03.2007, at 15:25, Gregg Wonderly wrote: > My preferred structure is. > > byte arr[ len ]; > int cnt; > int off = 0; > while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { > off += cnt; > } > > This keeps you from adding -1 to pos when the read returns -1. It > also skips > out when the read is 0 bytes which, is not a described EOF in > InputStream java > docs, but is a condition I want to be aware of. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Mar 6 14:47:44 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 Mar 2007 14:47:44 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: Just FYI, rxtx will usually not break out on EINTER. The code in the native library usually does something close to this: do { read(...) } while ( !done && errno==EINTR ); Obviously there is a little more involved but it will retry on EINTER if not done. On Tue, 6 Mar 2007, Joachim Buechse wrote: > The code I copied was from a file resource reader, it shouldn't > really be applied to networking/external IO code. Mea culpa. > > However aborting when you get 0 from read is not always what you want > either (you kind of indicated that already). Some unix java > implementations will return 0 if the kernel read was aborted with > EINTER, which is rarely the point where you want to abort your read - > at least not without further checks. A "complete" solution always > depends on the events you need to handle and the time the total read > could take in reality. In some cases it's worth checking > Thread.isInterrupted() in the loop, some code re-loops on 0 but only > a limited number of times, some check a total timeout limit, etc... > > Best regards, > Joachim > > On 05.03.2007, at 15:25, Gregg Wonderly wrote: >> My preferred structure is. >> >> byte arr[ len ]; >> int cnt; >> int off = 0; >> while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { >> off += cnt; >> } >> >> This keeps you from adding -1 to pos when the read returns -1. It >> also skips >> out when the read is 0 bytes which, is not a described EOF in >> InputStream java >> docs, but is a condition I want to be aware of. >> >> Gregg Wonderly >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 gjhanna at gmail.com Thu Mar 8 13:42:52 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Fri, 9 Mar 2007 09:42:52 +1300 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? Message-ID: I've just struck an issue using rxtx in a multi-threaded environment: If I have 3 threads trying to open *the same* comm-port I get a deadlock in CommPortIdentifier.open If I have just 2, it works fine - I get a PortInUseException which is nice and I can handle it. The 3 thread->deadlock thing is causing me issues. (Sample code below). This is from the java thread-dump Found one Java-level deadlock: ============================= "Thread-2": waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object ), which is held by "Thread-1" "Thread-1": waiting to lock monitor 0x0003e9cc (object 0x2450e108, a gnu.io.CommPortIdentifier), which is held by "Thread-2" Java stack information for the threads listed above: =================================================== "Thread-2": at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:329) - waiting to lock <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) "Thread-1": at java.lang.Object.wait(Native Method) - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) - locked <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) (Apart from this, rxtx is working fantastically for us). I'm thinking I'll have to implement some sort of locking mechanism that *doesn't* use java synchronization to prevent this situation. (Which doesn't sound like a good idea to me). Any ideas? Thanks, Greg Hanna ============= RXTXLockTest.java ======================================== import gnu.io.CommPort; import gnu.io.CommPortIdentifier; /** * @author Greg Hanna * Minimal code to create a deadlock with rxtx in multithreaded open */ public class RXTXLockTest { public static void main(String[] args) { try { CommPortIdentifier cpiCom1 = CommPortIdentifier.getPortIdentifier ("COM14"); OpenThread t1 = new OpenThread (" one ", cpiCom1); OpenThread t2 = new OpenThread (" two ", cpiCom1); OpenThread t3 = new OpenThread (" 003 ", cpiCom1); t1.start(); t2.start(); t3.start(); // comment this out and it runs with (expected) PortInUseException } catch (Exception e) { e.printStackTrace(); } } } class OpenThread extends Thread { String name; CommPortIdentifier cpi; CommPort cp; public OpenThread (String name, CommPortIdentifier cpi) { this.name = name; this.cpi = cpi; System.out.println (System.currentTimeMillis() + name + " thread created"); } public void run () { try { System.out.println (System.currentTimeMillis() + name + " opening"); cp = cpi.open(name, 2000); System.out.println (System.currentTimeMillis() + name + " opened - sleeping"); sleep (2000); // do the serial comms with the device. System.out.println (System.currentTimeMillis() + name + " slept - closing"); cp.close(); System.out.println (System.currentTimeMillis() + name + " closed - exiting"); } catch (Exception e) { System.out.println ("Error in thread: " + name ); e.printStackTrace(); } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070308/d9a163c5/attachment-0005.html From eu259473 at tele2.it Fri Mar 9 02:46:20 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 09 Mar 2007 10:46:20 +0100 Subject: [Rxtx] rxtx: tru64 unix make fails Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070309/3b654523/attachment-0005.html From lyon at docjava.com Fri Mar 9 03:58:32 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 Mar 2007 05:58:32 -0500 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi All, The deadlock issue is one that I have been thinking about for some time now. It seems to me that we need a resource manager that enables assignment to a known process. The one thing that seems important about serial ports is that two applications should not use the same serial port at the same time. When this happens, it throws an exception. OK. The exception is a response to a lock condition that arises from an unavailable resource. An abstract implementation (not born of native methods) might assign a serial port to an application, until the application releases it (or is forced to release it by some kill mechanism). Some resources (like a registry) can be reused. But others, like the serial port, cannot. In the case of the serial port, we would like, I think, to have the flyweight design pattern without sharing and with object assignment tracking. A means of breaking deadlock (like a leasing mechanism) seems very useful, to me. My guess is that we can serialize the state of the Parametric Singleton Pattern (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) into the Preferences of the System. Preferences.systemRoot() might help with that. When a resource is checked out, the lease time and owner are listed. A thread that does this can be killed, but applications outside of Java are problematic. There is a compelling problem here. It is not just serial ports. Sound cards, cameras, microphones, files, tape drives, etc. All are consumed resources that are assigned to an application (or user) and deprive other applications, or users, from use. What, if anything, should we do? At present we throw PortInUseExceptions. Is that it? Can we do better? OK, the port is in use. Now what? Do I have to be root to go remove lock files and kill applications? Is there a better way? Thanks! - Doug >I've just struck an issue using rxtx in a multi-threaded environment: > >If I have 3 threads trying to open *the same* >comm-port I get a deadlock in >CommPortIdentifier.open >If I have just 2, it works fine - I get a >PortInUseException which is nice and I can >handle it. > >The 3 thread->deadlock thing is causing me issues. >(Sample code below). > >This is from the java thread-dump > >Found one Java-level deadlock: >============================= >"Thread-2": > waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), > which is held by "Thread-1" >"Thread-1": > waiting to lock monitor 0x0003e9cc (object >0x2450e108, a gnu.io.CommPortIdentifier ), > which is held by "Thread-2" > >Java stack information for the threads listed above: >=================================================== >"Thread-2": > at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) > - waiting to lock <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) >"Thread-1": > at java.lang.Object.wait(Native Method) > - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) > - locked <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) > > >(Apart from this, rxtx is working fantastically for us). > >I'm thinking I'll have to implement some sort of >locking mechanism that *doesn't* use java >synchronization to prevent this situation. >(Which doesn't sound like a good idea to me). > >Any ideas? > >Thanks, > >Greg Hanna > >============= RXTXLockTest.java ======================================== > >import gnu.io.CommPort; >import gnu.io.CommPortIdentifier; > >/** > * @author Greg Hanna > * Minimal code to create a deadlock with rxtx in multithreaded open > */ >public class RXTXLockTest { > ? > ?public static void main(String[] args) { > ?try { > ?CommPortIdentifier cpiCom1 = >CommPortIdentifier.getPortIdentifier ("COM14"); > ?OpenThread t1 = new OpenThread (" one ", cpiCom1); > ?OpenThread t2 = new OpenThread (" two ", cpiCom1); > ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); > ?t1.start(); > ?t2.start(); > ?t3.start(); // comment this out >and it runs with (expected) PortInUseException > ?} catch (Exception e) { > ?e.printStackTrace(); > ?} > ?} >} > >class OpenThread extends Thread { > ?String name; > ?CommPortIdentifier cpi; > ?CommPort cp; > ?public OpenThread (String name, CommPortIdentifier cpi) { > ? this.name = name; > ?this.cpi = cpi; > ?System.out.println >(System.currentTimeMillis() + name + " thread >created"); > ?} > ?public void run () { > ?try { > ?System.out.println >(System.currentTimeMillis() + name + " opening"); > ?cp = cpi.open(name, 2000); > ?System.out.println >(System.currentTimeMillis() + name + " opened - >sleeping"); > ?sleep (2000); // do the serial comms with the device. > ?System.out.println >(System.currentTimeMillis() + name + " slept - >closing"); > ?cp.close(); > ?System.out.println >(System.currentTimeMillis() + name + " closed - >exiting"); > ?} catch (Exception e) { > System.out.println ("Error in thread: " + name ); > ?e.printStackTrace(); > ?} > ?} >} > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Mar 9 06:37:45 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 Mar 2007 06:37:45 -0700 (MST) Subject: [Rxtx] rxtx: tru64 unix make fails In-Reply-To: References: Message-ID: On Fri, 9 Mar 2007, "Giuseppe Marchese" wrote: > Sorry for delay. > ? > This is log for ./configure and make > error. > ? > thanks for attention > ? > Make: '%.java,$(TOP)/$(CLASSDEST)/%.class,$(wildcard $(SPATH)/*.java)': extra chars.? > Stop. > Hi Giuseppe You need to use GNU make with the Makefile. I suspect the tru64 make is not happy with those rules. > configure: exit 0 Looks like configure is fairly happy. From tjarvi at qbang.org Sat Mar 10 07:43:51 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 07:43:51 -0700 (MST) Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi Doug I have very little time to look into this further but what we could do is open up an rxtx 3 devel branch in which a proof of concept could be worked on. It could be the proof of concept for a JSR others including Sun could look at/work on or parts of it could be recycled in a JSR. I'm working very hard on rxtx right now but it does not show. I'm looking at win64, mac intel/ppc, usb bluetooth and usb serial dongles. Some are going to be more tested than others but they are all on the plate. I'll be pushing all the fixes upstream when they are done. So I'm very busy in 2.1 but we could open a new branch. On Fri, 9 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > The deadlock issue is one that I have been thinking about > for some time now. > It seems to me that we need a resource manager that enables assignment > to a known process. > > The one thing that seems important about serial > ports is that two applications should not use the > same serial port at the same time. When this > happens, it throws an exception. > OK. > > The exception is a response to a lock condition that > arises from an unavailable resource. > > An abstract implementation (not born of native methods) might > assign a serial port to an application, until the > application releases it (or is forced to release > it by some kill mechanism). > > Some resources (like a registry) can be reused. > But others, like the serial port, > cannot. > > In the case of the serial port, we would like, I think, to > have the flyweight design pattern > without sharing and with object assignment tracking. > A means of breaking deadlock (like a leasing > mechanism) seems very useful, to me. > > My guess is that we can serialize the state of the Parametric Singleton Pattern > (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) > into the Preferences of the System. Preferences.systemRoot() might help > with that. When a resource is checked out, the lease time and owner are > listed. A thread that does this can be killed, but applications outside of Java > are problematic. > > There is a compelling problem here. It is not just serial ports. > Sound cards, cameras, microphones, files, tape drives, etc. All are consumed > resources that are assigned to an application (or > user) and deprive other applications, > or users, from use. > > What, if anything, should we do? At present we throw PortInUseExceptions. > Is that it? > Can we do better? > OK, the port is in use. Now what? > Do I have to be root to go remove lock files and kill applications? > Is there a better way? > > Thanks! > - Doug > >> I've just struck an issue using rxtx in a multi-threaded environment: >> >> If I have 3 threads trying to open *the same* >> comm-port I get a deadlock in >> CommPortIdentifier.open >> If I have just 2, it works fine - I get a >> PortInUseException which is nice and I can >> handle it. >> >> The 3 thread->deadlock thing is causing me issues. >> (Sample code below). >> >> This is from the java thread-dump >> >> Found one Java-level deadlock: >> ============================= >> "Thread-2": >> waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), >> which is held by "Thread-1" >> "Thread-1": >> waiting to lock monitor 0x0003e9cc (object >> 0x2450e108, a gnu.io.CommPortIdentifier ), >> which is held by "Thread-2" >> >> Java stack information for the threads listed above: >> =================================================== >> "Thread-2": >> at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) >> - waiting to lock <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> "Thread-1": >> at java.lang.Object.wait(Native Method) >> - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) >> - locked <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> >> >> (Apart from this, rxtx is working fantastically for us). >> >> I'm thinking I'll have to implement some sort of >> locking mechanism that *doesn't* use java >> synchronization to prevent this situation. >> (Which doesn't sound like a good idea to me). >> >> Any ideas? >> >> Thanks, >> >> Greg Hanna >> >> ============= RXTXLockTest.java ======================================== >> >> import gnu.io.CommPort; >> import gnu.io.CommPortIdentifier; >> >> /** >> * @author Greg Hanna >> * Minimal code to create a deadlock with rxtx in multithreaded open >> */ >> public class RXTXLockTest { >> ? >> ?public static void main(String[] args) { >> ?try { >> ?CommPortIdentifier cpiCom1 = >> CommPortIdentifier.getPortIdentifier ("COM14"); >> ?OpenThread t1 = new OpenThread (" one ", cpiCom1); >> ?OpenThread t2 = new OpenThread (" two ", cpiCom1); >> ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); >> ?t1.start(); >> ?t2.start(); >> ?t3.start(); // comment this out >> and it runs with (expected) PortInUseException >> ?} catch (Exception e) { >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> class OpenThread extends Thread { >> ?String name; >> ?CommPortIdentifier cpi; >> ?CommPort cp; >> ?public OpenThread (String name, CommPortIdentifier cpi) { >> ? this.name = name; >> ?this.cpi = cpi; >> ?System.out.println >> (System.currentTimeMillis() + name + " thread >> created"); >> ?} >> ?public void run () { >> ?try { >> ?System.out.println >> (System.currentTimeMillis() + name + " opening"); >> ?cp = cpi.open(name, 2000); >> ?System.out.println >> (System.currentTimeMillis() + name + " opened - >> sleeping"); >> ?sleep (2000); // do the serial comms with the device. >> ?System.out.println >> (System.currentTimeMillis() + name + " slept - >> closing"); >> ?cp.close(); >> ?System.out.println >> (System.currentTimeMillis() + name + " closed - >> exiting"); >> ?} catch (Exception e) { >> System.out.println ("Error in thread: " + name ); >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 mm at UDel.Edu Sat Mar 10 14:48:32 2007 From: mm at UDel.Edu (Mike Markowski) Date: Sat, 10 Mar 2007 16:48:32 -0500 Subject: [Rxtx] rxtx and Sun's comm api Message-ID: <45F327B0.2060004@udel.edu> Hi all, I joined the list a few days ago and apologize for what is likely a frequently asked question, though I haven't yet found it anywhere. I learned about rxtx.org through the readme on Sun's version 2 of their comms api. They give recommendations in that readme regarding how a better comms api should be written. Is this the aim of rxtx.org? I wrote an app on my linux box using the Sun comms api (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the fact that only linux and Solaris are supported. So I'm glad to find rxtx.org and am just reading up on how make the conversion so Windows users will be able to run the program as well. At the same time I'm just curious if rxtx.org and Sun are both heading in the same direction. Thanks for any background or historical info. Feel free to point me to any www pages if my googling has just completely missed the target! Thanks again, Mike From tjarvi at qbang.org Sat Mar 10 15:35:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 15:35:25 -0700 (MST) Subject: [Rxtx] rxtx and Sun's comm api In-Reply-To: <45F327B0.2060004@udel.edu> References: <45F327B0.2060004@udel.edu> Message-ID: On Sat, 10 Mar 2007, Mike Markowski wrote: > Hi all, > > I joined the list a few days ago and apologize for what is likely a > frequently asked question, though I haven't yet found it anywhere. I > learned about rxtx.org through the readme on Sun's version 2 of their > comms api. They give recommendations in that readme regarding how a > better comms api should be written. Is this the aim of rxtx.org? > > I wrote an app on my linux box using the Sun comms api > (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the > fact that only linux and Solaris are supported. So I'm glad to find > rxtx.org and am just reading up on how make the conversion so Windows > users will be able to run the program as well. At the same time I'm > just curious if rxtx.org and Sun are both heading in the same direction. > > Thanks for any background or historical info. Feel free to point me to > any www pages if my googling has just completely missed the target! > I do not have any news (good or bad) concerning RXTX and Sun working together but perhaps others here do. The main goal of RXTX is to expose POSIX termios interfaces to java users. The future support of javax.comm is questionable. We do not have resources for everything. gnu.io (RXTX 2.1) will be supported going forward and functions the same as CommAPI 2.0. If you have control of the source code you are working with, I would not advise using CommAPI 2.0 javax.comm. We do support CommAPI 2.0 javax.comm for older applications but I do not think that will last much longer for practical reasons. The download interest in CommAPI 2.0 javax.comm support is becomming negligible on this end. There has been discussion of a JSR effort but I do not know of any status change since it was mentioned. One problem with a JSR is that even a light weight process is going to be difficult for RXTX at this time. Maybe that will change in the future but then again it may not. For now, we are just going forward 'as is' in rxtx 2.1 with package gnu.io while trying as a secondary effort to backport the changes to rxtx 2.0 for javax.comm support for users that do not have a choice. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Mar 11 07:19:40 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 11 Mar 2007 08:19:40 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: Hi All, I have been a proponent of a JSR that makes use of RXTX. I have executed the proper agreements with Sun. At this point we are in the: Early Draft Review of Draft Specifications Stage. The best thing to do is to enter the quiet period and create a specification. The question of exactly how we, as a group, want to approach this problem, remains open. Typically, we should have both a specification and a reference implementation. Thus, it would be to our best advantage to have a nice, stable, cross platform RXTX distro that adheres to the groups specification. Now, from a specification standpoint, my personal view on the matter is that we create a series of interfaces, with nice documentation (or at least javadoc). Is this a good idea? Should we have a pure interface specification for the communication API? There are several issues, in my mind, which still weigh on us. Hot-pluggable dongles, long discovery process on pop-up ports, lack of uniformity on device names, lack of uniformity on locking, a precise understanding of how the SerialPortResourceManager works (or even if we should have one). The more questions we answer in our reference implementation, the better our specification will get. RXTX is a good working prototype, but, I don't know if that is what we want to use for a specification. Here is what I have for a CommPortInterface: */ public interface CommPortInterface { /** * @return a string representation of this port. */ String toString(); /** * Gets the name of the communications port. This name should correspond to * something the user can identify, like the label on the hardware. * @return name of the port */ String getName(); /** * @return an input stream that can be used to read data from the * communications port. If the port doesn't support reading data, this * method returns null. *

* The blocking behaviour of this input stream depends on the threshold * and timeout values, as shown below for a read buffer size of n * bytes: * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ThresholdTimeoutBlocking behaviour
StateValueStateValue
disableddisabledblock until data is available
enabledm bytesdisabledblock until min(m, n) bytes are available
disabledenabledt msblock for t ms or until data is available
enabledm bytesenabledt msblock for t ms or until min(m, n) bytes are * available
* @throws java.io.IOException */ InputStream getInputStream() throws IOException; /** * @return an output stream that can be used to send data to the * communications port. If the port doesn't support sending data, this * method returns null. * @throws java.io.IOException */ OutputStream getOutputStream() throws IOException; /** * Closes this communications port. * All PortOwnershipListeners will be? * notified of this change of ownership. Further method calls on this? * object will throw IllegalStateException. Further calls on the? * associated InputStream or OutputStream will throw IOException. *

* Close does not block. Undelivered data is discarded. Blocked read and? * write operations are aborted if the underlying operating systems? * supports an IO abort mechanism. To await the delivery of undelivered? * data call OutputStream.flush() or OutputStream.close() before calling? * Port.close(). */ void close(); /** * Enables receive threshold. * When the specified threshold number of bytes are retrieved, read will * return immediately. * * @param thresh the number of bytes in the input buffer * @throws gnu.io.UnsupportedCommOperationException * if receive threshold is * not supported by the driver * @see #disableReceiveThreshold */ void enableReceiveThreshold(int thresh) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive threshold. * * @see #enableReceiveThreshold */ void disableReceiveThreshold(); /** * @return true if receive threshold is enabled. * * @see #enableReceiveThreshold */ boolean isReceiveThresholdEnabled(); /** * @return the receive threshold value. If receive threshold is diabled * or not supported, this value is meaningless. * * @see #enableReceiveThreshold */ int getReceiveThreshold(); /** * Enables receive timeout. * When the specified number of milliseconds have elapsed, read will * return immediately. * * @param rcvTimeout the number of milliseconds to block for * @throws gnu.io.UnsupportedCommOperationException * if receive timeout is * not supported by the driver * @see #disableReceiveTimeout */ void enableReceiveTimeout(int rcvTimeout) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive timeout. * * @see #enableReceiveTimeout */ void disableReceiveTimeout(); /** * @return true if receive timeout is enabled. * * @see #enableReceiveTimeout */ boolean isReceiveTimeoutEnabled(); /** * @return the receive timeout value. If receive timeout is diabled * or not supported, this value is meaningless. * * @see #enableReceiveTimeout */ int getReceiveTimeout(); /** * Enables receive framing. * The supplied byte value in the input suggests the end of the received * frame, and read returns immediately. Only the low 8 bits of the * supplied value are significant. * * @param framingByte the frame delimiter * @throws gnu.io.UnsupportedCommOperationException * if receive framing is * not supported by the driver * @see #disableReceiveFraming */ void enableReceiveFraming(int framingByte) throws UnsupportedCommOperationException; /** * Disables receive framing. * * @see #enableReceiveFraming */ void disableReceiveFraming(); /** * @return true if receive framing is enabled. * * @see #enableReceiveFraming */ boolean isReceiveFramingEnabled(); /** * @return true if receive framing byte. If receive framing is diabled * or not supported, this value is meaningless. * * @see #enableReceiveFraming */ int getReceiveFramingByte(); /** * Sets the input buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setInputBufferSize(int size); /** * @return the input buffer size. * The driver may choose not to report correct values. */ int getInputBufferSize(); /** * Sets the output buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setOutputBufferSize(int size); /** * @return the output buffer size. * The driver may choose not to report correct values. */ int getOutputBufferSize(); } What do you think of that? Note the wishy washy nature of the spec: The driver may choose to ignore this method. Is that good enough for us? Thanks! - Doug From ra85551 at gmail.com Sun Mar 11 08:44:45 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Sun, 11 Mar 2007 17:44:45 +0300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hello, world! I am writing application that communicates with modem via AT commands. My OS is Linux Kubuntu Feisty Herd, to ensure that my application will run properly under Windows XP I installed VMWare server. When I tried to send AT command and evaluate modem answer under WinXP @ VMWare server, I actually didn't receive anything. I think that VM settings are right, because I do can communicate with modem by using standard HyperTerminall as well as I can do on native Windows. So, why RXTX doesn't work under VM, but works under Linux and pure Windows XP (i tested it there) well? The send/receive method code follows. private String sendATCommand(String command, final String waitFor, final boolean isRegex, boolean isAddCRLF, long timeout) throws BeaconConnectException { final long POLL_PERIOD = 100; final int BUFFER_SIZE = 512; final byte[] buffer = new byte[BUFFER_SIZE]; final InputStream serialInput; final OutputStream serialOutput; try { serialInput = serialPort.getInputStream(); if (command != null) { serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } } catch (IOException e) { throw new MyException("serial I/O error"); } TimerTask task = new TimerTask() { int offset = 0; int bytesRead; public synchronized void run() { try { if (serialInput.available() > 0) { bytesRead = serialInput.read(buffer, offset, BUFFER_SIZE - offset); } else { return; } } catch (IOException e) { // do nothing - maybe next time we'll read something } offset += bytesRead; if (waitFor != null) { String temporary = new String(buffer, 0, offset).trim(); if (isRegex && temporary.matches(waitFor) || temporary.contains(waitFor)) { cancel(); notify(); } } } }; Timer timer = new Timer(); timer.schedule(task, POLL_PERIOD, POLL_PERIOD); synchronized (task) { try { task.wait(timeout); task.cancel(); } catch (InterruptedException e) { } } //Cut off leading and trailing CRs, LFs and zeroes String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); System.out.println(response); return response; } -- Pavel Parkhomenko From tjarvi at qbang.org Sun Mar 11 11:48:22 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:48:22 -0600 (MDT) Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: On Sun, 11 Mar 2007, Pavel Parkhomenko wrote: > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. > > private String sendATCommand(String command, final String waitFor, > final boolean isRegex, boolean isAddCRLF, long timeout) > throws BeaconConnectException > { > final long POLL_PERIOD = 100; > final int BUFFER_SIZE = 512; > final byte[] buffer = new byte[BUFFER_SIZE]; > final InputStream serialInput; > final OutputStream serialOutput; > try > { > serialInput = serialPort.getInputStream(); > if (command != null) > { > serialOutput = serialPort.getOutputStream(); > if (isAddCRLF) > { > command += "\r\n"; > } > System.out.println(command); > serialOutput.write(command.getBytes()); > } > } > catch (IOException e) > { > throw new MyException("serial I/O error"); > } > > TimerTask task = new TimerTask() > { > int offset = 0; > int bytesRead; > public synchronized void run() > { > try > { > if (serialInput.available() > 0) > { > bytesRead = serialInput.read(buffer, offset, > BUFFER_SIZE - offset); > } > else > { > return; > } > } > catch (IOException e) > { > // do nothing - maybe next time we'll read something > } > offset += bytesRead; > if (waitFor != null) > { > String temporary = new String(buffer, 0, offset).trim(); > if (isRegex && temporary.matches(waitFor) || > temporary.contains(waitFor)) > { > cancel(); > notify(); > } > } > } > }; > > Timer timer = new Timer(); > timer.schedule(task, POLL_PERIOD, POLL_PERIOD); > synchronized (task) { > try > { > task.wait(timeout); > task.cancel(); > } > catch (InterruptedException e) > { > } > } > //Cut off leading and trailing CRs, LFs and zeroes > String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); > System.out.println(response); > return response; > } > > > Hi Pavel VMWare should not be a problem. I've used it in the past - though not with a modem. Make sure nothing else is using the modem. Then look in the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an example that should work. Note that modems could care less what OS is on top. If you are trying to match new lines to the OS and sending it to the mode for AT commands, thats probably a mistake. Also it would not hurt to print out the individual bytes that you are sending to make sure they did not get mangled along the path. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 11:55:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:55:48 -0600 (MDT) Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: On Sun, 11 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > I have been a proponent of a JSR that makes > use of RXTX. I have executed the proper agreements with Sun. > > At this point we are in the: > Early Draft Review of Draft Specifications Stage. > > The best thing to do is to enter the quiet period and create > a specification. The question of exactly how we, as a group, > want to approach this problem, remains open. > > Typically, we should have both a specification and a reference > implementation. Thus, it would be to our best advantage to have > a nice, stable, cross platform RXTX distro that adheres to the > groups specification. > > Now, from a specification standpoint, my personal view on the matter is > that we create a series of interfaces, with nice documentation (or at least > javadoc). > > Is this a good idea? Should we have a pure interface specification for > the communication API? > > There are several issues, in my mind, which still weigh on us. > Hot-pluggable dongles, long discovery process on pop-up ports, > lack of uniformity on device names, lack of uniformity on locking, > a precise understanding of how the SerialPortResourceManager > works (or even if we should have one). > > The more questions we answer in our reference implementation, the > better our specification will get. RXTX is a good working prototype, > but, I don't know if that is what we want to use for a specification. > > Here is what I have for a CommPortInterface: > */ > public interface CommPortInterface { Hi Doug, I can start going through the method interfaces later this week and giving feedback. I would suggest that the JSR should not be too generic in nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel drivers that intend to look like EIA232 ports at the kernel driver level. some ideas: EIA232PortInterface TermiosInterface SerialPortInterface Something that differentiates this from thing like USB, I2C, ... which should not have to deal with legacy serial claiming to be the comm api. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 12:52:19 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 12:52:19 -0600 (MDT) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: No news is good news with these posts. I'll start the process of pinging legal a week from Monday on my end if nobody has objections to the proposal. I just want to make sure everyone has time to raise objections. Obviously, anyone can fork from a previous version if they don't like the new license. I suspect we can avoid that though. On Sun, 4 Mar 2007, Trent Jarvi wrote: > > For those that are wondering what is going on here, this > next bit is the meat of the changes. We agreed a long time > ago to put this disclaimer in. We did a so so job. It was > in rxtx 2.0, not well written, ... So some groups using > rxtx that would like to ship rxtx so users don't need to > download, install, go to the mail-list to find why it failed, > ... Then their legal teams tell them section 5 paragraph 2 > is a show stopper. > > That was never the intent. > > > Now going through what remains... > >> and might need a (TM) suffix to make Sun happy. > > Added disclaimer at the ended 'all trademarks belong...' > >> * Line #15ff - static vs. dynamic linking - you did >> not transcribe the text from the "controlled >> interface exception" when writing this text - and >> this was good so, because these terms originally >> refer to the GPL rather than the LGPL. I think though, >> that these 4 lines are the most important ones and >> should thus be really really clear. I hope that I >> meet your original intent with the following >> suggestions: >> 1.) Instead of "A program.." it would be better to >> say "An exectuable.." in order to be closer to >> the LGPL text. > > OK. As you can see I was trying to adjust GNU text there > for the LGPL. > >> 2.) It would be better to say .. "by being dynamically >> linked with it" to clearly indicate that dynamic >> linking is meant. The matter of compilation is >> already covered by the LGPL so mentioning it again >> just leads to confusion. > > used dynamically linked terminology. > >> 3.) It would be better to say .. "is considered a >> work that uses the library in contrast to section >> 5 of the LGPL, so the terms of the LGPL do not >> apply to the resulting executable". > > I tried to address this more upfront with an intent statement. > Let me know if you have problems with it. I also tried to > make it a little more clear what was derived from the GNU > solution by moving the link location closer to GNU's suggestion. > >> >> Note that LGPL section 5 says: ..."is called a >> "work that uses the Library". Such a work, in isolation, >> is not a derivative work of the Library, and therefore >> falls outside the scope of this License." >> The next paragraph of the LGPL is exactly the problematic >> one that I hope is clarified by the exception terms you >> give. >> > > Thats the intent. Here is the combined fixes. Note that only the > material in /*-- --*/ is being touched. The new GPL license is > there but unmodified. > > > ------------------------ begin proposed new license ------------------- > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Lesser General Public > | License as published by the Free Software Foundation; either > | version 2.1 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Lesser General Public License for more details. > | > | An executable that contains no derivative of any portion of RXTX, but > | is designed to work with RXTX by being dynamically linked with it, > | is considered a "work that uses the Library" subject to the terms and > | conditions of the GNU Lesser General Public License. > | > | The following has been added to the RXTX License to remove > | any confusion about linking to RXTX. We want to allow in part what > | section 5, paragraph 2 of the LGPL does not permit in the special > | case of linking over a controlled interface. The intent is to add a > | Java Specification Request or standards body defined interface in the > | future as another exception but one is not currently available. > | > | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface > | > | As a special exception, the copyright holders of RXTX give you > | permission to link RXTX with independent modules that communicate with > | RXTX solely through the Sun Microsytems CommAPI interface version 2, > | regardless of the license terms of these independent modules, and to copy > | and distribute the resulting combined work under terms of your choice, > | provided that every copy of the combined work is accompanied by a complete > | copy of the source code of RXTX (the version of RXTX used to produce the > | combined work), being distributed under the terms of the GNU Lesser General > | Public License plus this exception. An independent module is a > | module which is not derived from or based on RXTX. > | > | Note that people who make modified versions of RXTX are not obligated > | to grant this special exception for their modified versions; it is > | their choice whether to do so. The GNU Lesser General Public License > | gives permission to release a modified version without this exception; this > | exception also makes it possible to release a modified version which > | carries forward this exception. > | > | You should have received a copy of the GNU Lesser General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > | All trademarks belong to their respective owners. > --------------------------------------------------------------------------*/ > > The original GNU Lesser General Public License Follows. > > > GNU LESSER GENERAL PUBLIC LICENSE > Version 2.1, February 1999 > > Copyright (C) 1991, 1999 Free Software Foundation, Inc. > 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > Everyone is permitted to copy and distribute verbatim copies > of this license document, but changing it is not allowed. > > [This is the first released version of the Lesser GPL. It also counts > as the successor of the GNU Library Public License, version 2, hence > the version number 2.1.] > > Preamble > > The licenses for most software are designed to take away your > freedom to share and change it. By contrast, the GNU General Public > Licenses are intended to guarantee your freedom to share and change > free software--to make sure the software is free for all its users. > > This license, the Lesser General Public License, applies to some > specially designated software packages--typically libraries--of the > Free Software Foundation and other authors who decide to use it. You > can use it too, but we suggest you first think carefully about whether > this license or the ordinary General Public License is the better > strategy to use in any particular case, based on the explanations below. > > When we speak of free software, we are referring to freedom of use, > not price. Our General Public Licenses are designed to make sure that > you have the freedom to distribute copies of free software (and charge > for this service if you wish); that you receive source code or can get > it if you want it; that you can change the software and use pieces of > it in new free programs; and that you are informed that you can do > these things. > > To protect your rights, we need to make restrictions that forbid > distributors to deny you these rights or to ask you to surrender these > rights. These restrictions translate to certain responsibilities for > you if you distribute copies of the library or if you modify it. > > For example, if you distribute copies of the library, whether gratis > or for a fee, you must give the recipients all the rights that we gave > you. You must make sure that they, too, receive or can get the source > code. If you link other code with the library, you must provide > complete object files to the recipients, so that they can relink them > with the library after making changes to the library and recompiling > it. And you must show them these terms so they know their rights. > > We protect your rights with a two-step method: (1) we copyright the > library, and (2) we offer you this license, which gives you legal > permission to copy, distribute and/or modify the library. > > To protect each distributor, we want to make it very clear that > there is no warranty for the free library. Also, if the library is > modified by someone else and passed on, the recipients should know > that what they have is not the original version, so that the original > author's reputation will not be affected by problems that might be > introduced by others. > > Finally, software patents pose a constant threat to the existence of > any free program. We wish to make sure that a company cannot > effectively restrict the users of a free program by obtaining a > restrictive license from a patent holder. Therefore, we insist that > any patent license obtained for a version of the library must be > consistent with the full freedom of use specified in this license. > > Most GNU software, including some libraries, is covered by the > ordinary GNU General Public License. This license, the GNU Lesser > General Public License, applies to certain designated libraries, and > is quite different from the ordinary General Public License. We use > this license for certain libraries in order to permit linking those > libraries into non-free programs. > > When a program is linked with a library, whether statically or using > a shared library, the combination of the two is legally speaking a > combined work, a derivative of the original library. The ordinary > General Public License therefore permits such linking only if the > entire combination fits its criteria of freedom. The Lesser General > Public License permits more lax criteria for linking other code with > the library. > > We call this license the "Lesser" General Public License because it > does Less to protect the user's freedom than the ordinary General > Public License. It also provides other free software developers Less > of an advantage over competing non-free programs. These disadvantages > are the reason we use the ordinary General Public License for many > libraries. However, the Lesser license provides advantages in certain > special circumstances. > > For example, on rare occasions, there may be a special need to > encourage the widest possible use of a certain library, so that it becomes > a de-facto standard. To achieve this, non-free programs must be > allowed to use the library. A more frequent case is that a free > library does the same job as widely used non-free libraries. In this > case, there is little to gain by limiting the free library to free > software only, so we use the Lesser General Public License. > > In other cases, permission to use a particular library in non-free > programs enables a greater number of people to use a large body of > free software. For example, permission to use the GNU C Library in > non-free programs enables many more people to use the whole GNU > operating system, as well as its variant, the GNU/Linux operating > system. > > Although the Lesser General Public License is Less protective of the > users' freedom, it does ensure that the user of a program that is > linked with the Library has the freedom and the wherewithal to run > that program using a modified version of the Library. > > The precise terms and conditions for copying, distribution and > modification follow. Pay close attention to the difference between a > "work based on the library" and a "work that uses the library". The > former contains code derived from the library, whereas the latter must > be combined with the library in order to run. > > GNU LESSER GENERAL PUBLIC LICENSE > TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION > > 0. This License Agreement applies to any software library or other > program which contains a notice placed by the copyright holder or > other authorized party saying it may be distributed under the terms of > this Lesser General Public License (also called "this License"). > Each licensee is addressed as "you". > > A "library" means a collection of software functions and/or data > prepared so as to be conveniently linked with application programs > (which use some of those functions and data) to form executables. > > The "Library", below, refers to any such software library or work > which has been distributed under these terms. A "work based on the > Library" means either the Library or any derivative work under > copyright law: that is to say, a work containing the Library or a > portion of it, either verbatim or with modifications and/or translated > straightforwardly into another language. (Hereinafter, translation is > included without limitation in the term "modification".) > > "Source code" for a work means the preferred form of the work for > making modifications to it. For a library, complete source code means > all the source code for all modules it contains, plus any associated > interface definition files, plus the scripts used to control compilation > and installation of the library. > > Activities other than copying, distribution and modification are not > covered by this License; they are outside its scope. The act of > running a program using the Library is not restricted, and output from > such a program is covered only if its contents constitute a work based > on the Library (independent of the use of the Library in a tool for > writing it). Whether that is true depends on what the Library does > and what the program that uses the Library does. > > 1. You may copy and distribute verbatim copies of the Library's > complete source code as you receive it, in any medium, provided that > you conspicuously and appropriately publish on each copy an > appropriate copyright notice and disclaimer of warranty; keep intact > all the notices that refer to this License and to the absence of any > warranty; and distribute a copy of this License along with the > Library. > > You may charge a fee for the physical act of transferring a copy, > and you may at your option offer warranty protection in exchange for a > fee. > > 2. You may modify your copy or copies of the Library or any portion > of it, thus forming a work based on the Library, and copy and > distribute such modifications or work under the terms of Section 1 > above, provided that you also meet all of these conditions: > > a) The modified work must itself be a software library. > > b) You must cause the files modified to carry prominent notices > stating that you changed the files and the date of any change. > > c) You must cause the whole of the work to be licensed at no > charge to all third parties under the terms of this License. > > d) If a facility in the modified Library refers to a function or a > table of data to be supplied by an application program that uses > the facility, other than as an argument passed when the facility > is invoked, then you must make a good faith effort to ensure that, > in the event an application does not supply such function or > table, the facility still operates, and performs whatever part of > its purpose remains meaningful. > > (For example, a function in a library to compute square roots has > a purpose that is entirely well-defined independent of the > application. Therefore, Subsection 2d requires that any > application-supplied function or table used by this function must > be optional: if the application does not supply it, the square > root function must still compute square roots.) > > These requirements apply to the modified work as a whole. If > identifiable sections of that work are not derived from the Library, > and can be reasonably considered independent and separate works in > themselves, then this License, and its terms, do not apply to those > sections when you distribute them as separate works. But when you > distribute the same sections as part of a whole which is a work based > on the Library, the distribution of the whole must be on the terms of > this License, whose permissions for other licensees extend to the > entire whole, and thus to each and every part regardless of who wrote > it. > > Thus, it is not the intent of this section to claim rights or contest > your rights to work written entirely by you; rather, the intent is to > exercise the right to control the distribution of derivative or > collective works based on the Library. > > In addition, mere aggregation of another work not based on the Library > with the Library (or with a work based on the Library) on a volume of > a storage or distribution medium does not bring the other work under > the scope of this License. > > 3. You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. To do > this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version 2, > instead of to this License. (If a newer version than version 2 of the > ordinary GNU General Public License has appeared, then you can specify > that version instead if you wish.) Do not make any other change in > these notices. > > Once this change is made in a given copy, it is irreversible for > that copy, so the ordinary GNU General Public License applies to all > subsequent copies and derivative works made from that copy. > > This option is useful when you wish to copy part of the code of > the Library into a program that is not a library. > > 4. You may copy and distribute the Library (or a portion or > derivative of it, under Section 2) in object code or executable form > under the terms of Sections 1 and 2 above provided that you accompany > it with the complete corresponding machine-readable source code, which > must be distributed under the terms of Sections 1 and 2 above on a > medium customarily used for software interchange. > > If distribution of object code is made by offering access to copy > from a designated place, then offering equivalent access to copy the > source code from the same place satisfies the requirement to > distribute the source code, even though third parties are not > compelled to copy the source along with the object code. > > 5. A program that contains no derivative of any portion of the > Library, but is designed to work with the Library by being compiled or > linked with it, is called a "work that uses the Library". Such a > work, in isolation, is not a derivative work of the Library, and > therefore falls outside the scope of this License. > > However, linking a "work that uses the Library" with the Library > creates an executable that is a derivative of the Library (because it > contains portions of the Library), rather than a "work that uses the > library". The executable is therefore covered by this License. > Section 6 states terms for distribution of such executables. > > When a "work that uses the Library" uses material from a header file > that is part of the Library, the object code for the work may be a > derivative work of the Library even though the source code is not. > Whether this is true is especially significant if the work can be > linked without the Library, or if the work is itself a library. The > threshold for this to be true is not precisely defined by law. > > If such an object file uses only numerical parameters, data > structure layouts and accessors, and small macros and small inline > functions (ten lines or less in length), then the use of the object > file is unrestricted, regardless of whether it is legally a derivative > work. (Executables containing this object code plus portions of the > Library will still fall under Section 6.) > > Otherwise, if the work is a derivative of the Library, you may > distribute the object code for the work under the terms of Section 6. > Any executables containing that work also fall under Section 6, > whether or not they are linked directly with the Library itself. > > 6. As an exception to the Sections above, you may also combine or > link a "work that uses the Library" with the Library to produce a > work containing portions of the Library, and distribute that work > under terms of your choice, provided that the terms permit > modification of the work for the customer's own use and reverse > engineering for debugging such modifications. > > You must give prominent notice with each copy of the work that the > Library is used in it and that the Library and its use are covered by > this License. You must supply a copy of this License. If the work > during execution displays copyright notices, you must include the > copyright notice for the Library among them, as well as a reference > directing the user to the copy of this License. Also, you must do one > of these things: > > a) Accompany the work with the complete corresponding > machine-readable source code for the Library including whatever > changes were used in the work (which must be distributed under > Sections 1 and 2 above); and, if the work is an executable linked > with the Library, with the complete machine-readable "work that > uses the Library", as object code and/or source code, so that the > user can modify the Library and then relink to produce a modified > executable containing the modified Library. (It is understood > that the user who changes the contents of definitions files in the > Library will not necessarily be able to recompile the application > to use the modified definitions.) > > b) Use a suitable shared library mechanism for linking with the > Library. A suitable mechanism is one that (1) uses at run time a > copy of the library already present on the user's computer system, > rather than copying library functions into the executable, and (2) > will operate properly with a modified version of the library, if > the user installs one, as long as the modified version is > interface-compatible with the version that the work was made with. > > c) Accompany the work with a written offer, valid for at > least three years, to give the same user the materials > specified in Subsection 6a, above, for a charge no more > than the cost of performing this distribution. > > d) If distribution of the work is made by offering access to copy > from a designated place, offer equivalent access to copy the above > specified materials from the same place. > > e) Verify that the user has already received a copy of these > materials or that you have already sent this user a copy. > > For an executable, the required form of the "work that uses the > Library" must include any data and utility programs needed for > reproducing the executable from it. However, as a special exception, > the materials to be distributed need not include anything that is > normally distributed (in either source or binary form) with the major > components (compiler, kernel, and so on) of the operating system on > which the executable runs, unless that component itself accompanies > the executable. > > It may happen that this requirement contradicts the license > restrictions of other proprietary libraries that do not normally > accompany the operating system. Such a contradiction means you cannot > use both them and the Library together in an executable that you > distribute. > > 7. You may place library facilities that are a work based on the > Library side-by-side in a single library together with other library > facilities not covered by this License, and distribute such a combined > library, provided that the separate distribution of the work based on > the Library and of the other library facilities is otherwise > permitted, and provided that you do these two things: > > a) Accompany the combined library with a copy of the same work > based on the Library, uncombined with any other library > facilities. This must be distributed under the terms of the > Sections above. > > b) Give prominent notice with the combined library of the fact > that part of it is a work based on the Library, and explaining > where to find the accompanying uncombined form of the same work. > > 8. You may not copy, modify, sublicense, link with, or distribute > the Library except as expressly provided under this License. Any > attempt otherwise to copy, modify, sublicense, link with, or > distribute the Library is void, and will automatically terminate your > rights under this License. However, parties who have received copies, > or rights, from you under this License will not have their licenses > terminated so long as such parties remain in full compliance. > > 9. You are not required to accept this License, since you have not > signed it. However, nothing else grants you permission to modify or > distribute the Library or its derivative works. These actions are > prohibited by law if you do not accept this License. Therefore, by > modifying or distributing the Library (or any work based on the > Library), you indicate your acceptance of this License to do so, and > all its terms and conditions for copying, distributing or modifying > the Library or works based on it. > > 10. Each time you redistribute the Library (or any work based on the > Library), the recipient automatically receives a license from the > original licensor to copy, distribute, link with or modify the Library > subject to these terms and conditions. You may not impose any further > restrictions on the recipients' exercise of the rights granted herein. > You are not responsible for enforcing compliance by third parties with > this License. > > 11. If, as a consequence of a court judgment or allegation of patent > infringement or for any other reason (not limited to patent issues), > conditions are imposed on you (whether by court order, agreement or > otherwise) that contradict the conditions of this License, they do not > excuse you from the conditions of this License. If you cannot > distribute so as to satisfy simultaneously your obligations under this > License and any other pertinent obligations, then as a consequence you > may not distribute the Library at all. For example, if a patent > license would not permit royalty-free redistribution of the Library by > all those who receive copies directly or indirectly through you, then > the only way you could satisfy both it and this License would be to > refrain entirely from distribution of the Library. > > If any portion of this section is held invalid or unenforceable under any > particular circumstance, the balance of the section is intended to apply, > and the section as a whole is intended to apply in other circumstances. > > It is not the purpose of this section to induce you to infringe any > patents or other property right claims or to contest validity of any > such claims; this section has the sole purpose of protecting the > integrity of the free software distribution system which is > implemented by public license practices. Many people have made > generous contributions to the wide range of software distributed > through that system in reliance on consistent application of that > system; it is up to the author/donor to decide if he or she is willing > to distribute software through any other system and a licensee cannot > impose that choice. > > This section is intended to make thoroughly clear what is believed to > be a consequence of the rest of this License. > > 12. If the distribution and/or use of the Library is restricted in > certain countries either by patents or by copyrighted interfaces, the > original copyright holder who places the Library under this License may add > an explicit geographical distribution limitation excluding those countries, > so that distribution is permitted only in or among countries not thus > excluded. In such case, this License incorporates the limitation as if > written in the body of this License. > > 13. The Free Software Foundation may publish revised and/or new > versions of the Lesser General Public License from time to time. > Such new versions will be similar in spirit to the present version, > but may differ in detail to address new problems or concerns. > > Each version is given a distinguishing version number. If the Library > specifies a version number of this License which applies to it and > "any later version", you have the option of following the terms and > conditions either of that version or of any later version published by > the Free Software Foundation. If the Library does not specify a > license version number, you may choose any version ever published by > the Free Software Foundation. > > 14. If you wish to incorporate parts of the Library into other free > programs whose distribution conditions are incompatible with these, > write to the author to ask for permission. For software which is > copyrighted by the Free Software Foundation, write to the Free > Software Foundation; we sometimes make exceptions for this. Our > decision will be guided by the two goals of preserving the free status > of all derivatives of our free software and of promoting the sharing > and reuse of software generally. > > NO WARRANTY > > 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO > WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. > EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR > OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY > KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE > IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE > LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME > THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. > > 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN > WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY > AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU > FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR > CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE > LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING > RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A > FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF > SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH > DAMAGES. > > END OF TERMS AND CONDITIONS > > How to Apply These Terms to Your New Libraries > > If you develop a new library, and you want it to be of the greatest > possible use to the public, we recommend making it free software that > everyone can redistribute and change. You can do so by permitting > redistribution under these terms (or, alternatively, under the terms of the > ordinary General Public License). > > To apply these terms, attach the following notices to the library. It is > safest to attach them to the start of each source file to most effectively > convey the exclusion of warranty; and each file should have at least the > "copyright" line and a pointer to where the full notice is found. > > > Copyright (C) > > This library is free software; you can redistribute it and/or > modify it under the terms of the GNU Lesser General Public > License as published by the Free Software Foundation; either > version 2.1 of the License, or (at your option) any later version. > > This library is distributed in the hope that it will be useful, > but WITHOUT ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > Lesser General Public License for more details. > > You should have received a copy of the GNU Lesser General Public > License along with this library; if not, write to the Free Software > Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > > Also add information on how to contact you by electronic and paper mail. > > You should also get your employer (if you work as a programmer) or your > school, if any, to sign a "copyright disclaimer" for the library, if > necessary. Here is a sample; alter the names: > > Yoyodyne, Inc., hereby disclaims all copyright interest in the > library `Frob' (a library for tweaking knobs) written by James Random Hacker. > > , 1 April 1990 > Ty Coon, President of Vice > > That's all there is to it! > ------------------------ end of proposed license ------------------ > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From gjhanna at gmail.com Sun Mar 11 14:21:17 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Mon, 12 Mar 2007 09:21:17 +1300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hi Pavel, We are using RXTX under VMWare server in production, quite satisfactorily. We're using Red Hat Enterprise Server 4, and ... Whatever the "enterprise" VMWare product is. Regards, Greg H > Subject: [Rxtx] RXTX under VMWare server > To: rxtx at qbang.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. [ ... snip ... ] -- Pavel Parkhomenko -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070311/4cebb6f9/attachment-0005.html From gergg at cox.net Sun Mar 11 23:39:19 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 12 Mar 2007 00:39:19 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: <45F4E787.6050502@cox.net> Trent Jarvi wrote: > I can start going through the method interfaces later this week and giving > feedback. I would suggest that the JSR should not be too generic in > nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel > drivers that intend to look like EIA232 ports at the kernel driver level. > > some ideas: > > EIA232PortInterface > TermiosInterface > SerialPortInterface > > Something that differentiates this from thing like USB, I2C, ... which > should not have to deal with legacy serial claiming to be the comm api. I'm going to throw out a suggestion, which I am mostly serious about. What would happen if we took the appropriate bits of the J2ME connector API, and just used that as the new COMM API so that finally JSE and JME had a common foundation for these kinds of things? Gregg Wonderly From ra85551 at gmail.com Mon Mar 12 09:08:37 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Mon, 12 Mar 2007 18:08:37 +0300 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Should any application use the modem, HyperTerminal won't be able to talk to the modem. But it actually can send and receive AT comands, while my application cannot :-( > Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Thansk for the reference. I examined that example and found that there's no significant differences between my read/write implementation and that one, except that SimpleSnuV1 listens for serialEvent's, but not for sake of data retrieval, just for printing them out - I don't know why ;-) > Note that modems could care less what OS is on top. If you are trying to > match new lines to the OS and sending it to the mode for AT commands, > thats probably a mistake. I do send strings to serial port, not to OS, and do try to get answers back. If it is the mistake, what's the right way? > Also it would not hurt to print out the > individual bytes that you are sending to make sure they did not get > mangled along the path. Yeah, I am printing these bytes before doing write, but it means that I only see what I intend to write. How can I ensure that these bytes have gone out of the box and reached my modem? BTW, I found that my send/receive method is complex enough, so I've rewritten it. Please, see the following code and point any mistakes, because I don't know where can they remain yet. private static final int LARGE_TIMEOUT = 15000; private static final int SMALL_TIMEOUT = 500; ... private String sendATCommand(String command, String waitFor, boolean isRegex, boolean isAddCRLF) throws BeaconConnectException { byte[] buffer = new byte[512]; int offset; String result = ""; try { if (waitFor != null) { serialPort.enableReceiveTimeout(LARGE_TIMEOUT); } else { serialPort.enableReceiveTimeout(SMALL_TIMEOUT); } if (command != null) { OutputStream serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } offset = 0; InputStream serialInput = serialPort.getInputStream(); while (serialInput.available() != -1) { int bytesRead = serialInput.read(buffer, offset, buffer.length - offset); if (bytesRead == 0) { break; } offset += bytesRead; result = new String(buffer, 0, offset).trim(); if (waitFor != null) { System.out.println(result); if (isRegex && result.matches(waitFor) || result.contains(waitFor)) { break; } } } } catch (UnsupportedCommOperationException e) { throw new MyException("unsupported operation"); } catch (IOException e) { throw new MytException("serial I/O error"); } return result; } -- Pavel Parkhomenko From clayno at hotpop.com Thu Mar 15 02:47:34 2007 From: clayno at hotpop.com (Christopher Layno) Date: Thu, 15 Mar 2007 16:47:34 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi, we're using the latest release of rxtx (2.1-7r2) for our system that has two applications using the library. one application sends requests to the modem while the other simply checks the modem status. we deployed our system on a pentium machine with red hat linux 9.0 installed. now the problem arises when these two applications try to access the same modem at the same time. one of them will eventually have to throw the PortInUseException as shown below: 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException gnu.io.PortInUseException: root PID = 743 Program = java root PID = 743 Program = java root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) this was expected. what we didn't expect though was that if we repeat the scenario 5 times, always 5 times, the application would also throw a VM error: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4473CD21 Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so Current Java thread: at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) - locked <0x44cfd4c8> (a gnu.io.CommPortIdentifier) at ************ at ************ - locked <0x4476a468> (a **********) at ************ at ************ at ************ at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java :261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages( TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run( TCPTransport.java:701) at java.lang.Thread.run(Thread.java:534) note: i replaced some sensitive data with asterisks our team has looked everywhere on the internet, including your mail archives, for a solution to this problem but to no avail. i really hope you could help us out on this one. thanks in advance! best regards, chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070315/1936460a/attachment-0005.html From tjarvi at qbang.org Fri Mar 16 04:30:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 04:30:25 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: On Thu, 15 Mar 2007, Christopher Layno wrote: > hi, > > we're using the latest release of rxtx (2.1-7r2) for our system that has two > applications using the library. one application sends requests to the modem > while the other simply checks the modem status. we deployed our system on a > pentium machine with red hat linux 9.0 installed. > > now the problem arises when these two applications try to access the same > modem at the same time. one of them will eventually have to throw the > PortInUseException as shown below: > > 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException > gnu.io.PortInUseException: root PID = 743 Program = java root PID = > 743 Program = java root PID = 743 Program = ??? root PID = 743 Program > = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root > PID = 743 Program = ??? root PID = 743 Program = ??? > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > > this was expected. what we didn't expect though was that if we repeat the > scenario 5 times, always 5 times, the application would also throw a VM > error: > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x4473CD21 > Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 > Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so > > Current Java thread: > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) Hi Chris The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. The code is originally by Werner Almesberger. He gave us permission to use it in rxtx. You might look at what has changed since 1998 in his fuser application. Or you can just do like other OSs and do the following in fuserImp.c JNIEXPORT jstring JNICALL Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv *env, jobject obj, jstring arg) { return (*env)->NewStringUTF(env, "Unknown Application"); } It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. -- Trent Jarvi tjarvi at qang.org From Adrien.TOS at ingenico.com Fri Mar 16 05:11:12 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Fri, 16 Mar 2007 12:11:12 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903CBC312@frsnprexc1.usr.ingenico.loc> Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070316/972ab214/attachment-0005.html From joachim at buechse.de Fri Mar 16 05:13:24 2007 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 16 Mar 2007 12:13:24 +0100 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. From tjarvi at qbang.org Fri Mar 16 16:36:29 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 16:36:29 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Fri Mar 16 16:02:23 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 16 Mar 2007 18:02:23 -0400 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Not all platforms are Unix based. Also mixing native library usage and command-line calls is not an elegant solution, IMHO. One or the other, but not both. Andre On 16-Mar-07, at 07:13 , Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is > trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We >> only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From clayno at hotpop.com Sun Mar 18 22:17:28 2007 From: clayno at hotpop.com (Christopher Layno) Date: Mon, 19 Mar 2007 12:17:28 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi everyone, thank you so much for your replies. they were really helpful. anyway, before i sent the email, my team was already implementing a temporary solution by using joachim's suggestion. we invoked a lsof command from our java code although i share the same concern with trent and andre-john about portability issues. that's why i said it's just temporary. my superiors have yet to approve our bug fix. so my question now is this: is recompiling the rxtx source code the only way to solve this problem? because if it's the only solution, then i think my superiors would rather have a new release from the rxtx community itself that fixes this bug(?) rather than have my team recompile the source code. best regards, chris Trent Jarvi wrote: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. ... It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070318/237463b2/attachment-0005.html From tjarvi at qbang.org Mon Mar 19 16:20:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Mar 2007 16:20:52 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: Hi Chris I can compile a new version after the 21st if you do not feel comfortable doing so. Please send me an email reminder off-line then. On Mon, 19 Mar 2007, Christopher Layno wrote: > hi everyone, > > thank you so much for your replies. they were really helpful. > > anyway, before i sent the email, my team was already implementing a > temporary solution by using joachim's suggestion. > we invoked a lsof command from our java code although i share the same > concern with trent and andre-john about > portability issues. that's why i said it's just temporary. my superiors have > yet to approve our bug fix. > > so my question now is this: is recompiling the rxtx source code the only way > to solve this problem? because if it's the only > solution, then i think my superiors would rather have a new release from the > rxtx community itself that fixes this bug(?) > rather than have my team recompile the source code. > > best regards, > > chris > > Trent Jarvi wrote: > > Hi Joachim > > It would be nice to have that functionality but calling the program > introduces too many issues imho. Explaining to someone why rxtx invoked a > rogue lsof does not sound very interesting. > > On Fri, 16 Mar 2007, Joachim Buechse wrote: > > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: > > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. > > _______________________________________________ > Rxtx mailing list > Rxtx 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 Eric.Arseneau at sun.com Tue Mar 20 11:47:33 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Tue, 20 Mar 2007 10:47:33 -0700 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 Message-ID: <46001E35.9040608@sun.com> Anyone have any experience with RXTX working with JDK 6 on other platforms ? From mm at UDel.Edu Tue Mar 20 12:18:29 2007 From: mm at UDel.Edu (Mike Markowski) Date: Tue, 20 Mar 2007 14:18:29 -0400 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 In-Reply-To: <46001E35.9040608@sun.com> References: <46001E35.9040608@sun.com> Message-ID: <46002575.4000306@udel.edu> Eric Arseneau wrote: > Anyone have any experience with RXTX working with JDK 6 on other platforms ? I'm using 32 bit intel, gentoo linux, jdk6 with no problems. My applications only use a serial port, though, nothing on the parallel port. Mike From falko.guderian at gmx.de Wed Mar 21 08:17:35 2007 From: falko.guderian at gmx.de (Falko Guderian) Date: Wed, 21 Mar 2007 15:17:35 +0100 Subject: [Rxtx] RXTX binaries for SH4 Message-ID: <46013E7F.40102@gmx.de> Dear developers, I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no possiblities to compile the source code. Better, I'm not able to do this at the moment. Can you provide me with rxtxSerial.dll (SH4) in the rxtx-2.1-8-testing version? (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) The reason for the testing version is I need custom baud rates. Thanks for help. Kind regards, Falko Guderian From tjarvi at qbang.org Wed Mar 21 21:38:37 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Mar 2007 21:38:37 -0600 (MDT) Subject: [Rxtx] RXTX binaries for SH4 In-Reply-To: <46013E7F.40102@gmx.de> References: <46013E7F.40102@gmx.de> Message-ID: On Wed, 21 Mar 2007, Falko Guderian wrote: > Dear developers, > > I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no > possiblities to compile the source code. Better, I'm not able to do this > at the moment. Can you provide me with rxtxSerial.dll (SH4) in the > rxtx-2.1-8-testing version? > (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) > > The reason for the testing version is I need custom baud rates. > > Thanks for help. > Hi Falko WinCE binary format is not supported by gcc. That makes compiling limited to those familiar with the WinCE tools. I hope someone is able to provide them for you but it is not likely. WinCE has been compiled by others in the past but rxtx.org builds have never included WinCE. There is some information with the source concerning WinCE builds if you decide to do it. We can share your results too if you like. The source in the WinCE has never been updated for the custom baud rate. That would need changes from the main source I presume. If you look at the source, you will note that Michal Hobot created a mini fork in the source to handle wince but it has not been updated for 3 years. -- Trent Jarvi tjarvi at qbang.org From Adrien.TOS at ingenico.com Thu Mar 22 07:08:55 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Thu, 22 Mar 2007 14:08:55 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Hi everybody, Do you have any comments on this issue? Thanks! AT ________________________________ De : Adrien TOS Envoy? : vendredi 16 mars 2007 12:11 ? : 'rxtx at qbang.org' Cc : Adrien TOS Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070322/2306c538/attachment-0005.html From jeremy.reeve at zen.co.uk Mon Mar 19 07:36:04 2007 From: jeremy.reeve at zen.co.uk (Jeremy S. Reeve) Date: Mon, 19 Mar 2007 13:36:04 +0000 Subject: [Rxtx] rxtx failing to compile on Fedora Core 6 Message-ID: <1174311364.21865.6.camel@d9thc> When trying to compile latest source : rxtx-2.1-7r2 I get the following when running configure: ---------------- checking os.version 2.6.18-1.2200.fc5smp WARNING: configure is having a hard time determining which directory contains the file jni_md.h. Edit Makefile and fix the variable JAVANATINC to point to the correct directory. The following options are available: /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/ /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/linux/ If there are more than one option available the first was selected. WARNING: Kernel include files do not match the current kernel configure: creating ./config.status ------------------------ which seems OK checking the resultant Makefile but when attempting to build with gmake install I get the following output : ---------------------- 34 problems (34 warnings)/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/javah -classpath .:/home/jsr/rxtxsrc/rxtx-2.1-7r2:/home/jsr/rxtxsrc/rxtx-2.1-7r2/src:/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/ext/RXTXcomm.jar -d i686-pc-linux-gnu -jni `(for i in CommDriver CommPortEnumerator CommPortIdentifier CommPort CommPortOwnershipListener Configure I2C I2CPortEvent I2CPortEventListener I2CPort LPRPort NoSuchPortException ParallelPortEvent ParallelPortEventListener ParallelPort PortInUseException Raw RawPortEvent RawPortEventListener RawPort RS485 RS485PortEvent RS485PortEventListener RS485Port RXTXCommDriver RXTXPort RXTXVersion SerialPortEvent SerialPortEventListener SerialPort UnsupportedCommOperationException UnSupportedLoggerException Zystem;do \ if grep > /dev/null native.* \( /home/jsr/rxtxsrc/rxtx-2.1-7r2/./src/$i.java; then \ echo gnu.io.$i; \ fi; \ done)` i686-pc-linux-gnu/gnu_io_CommPortIdentifier.h: No such file or directory make: *** [/home/jsr/rxtxsrc/rxtx-2.1-7r2/gnu/io/CommDriver.class] Error 1 ------------------------ Any ideas or pointers? Regards, Jeremy From tjarvi at qbang.org Sat Mar 24 08:12:54 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 Mar 2007 08:12:54 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > From Adrien.TOS at ingenico.com Sat Mar 24 11:53:22 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Sat, 24 Mar 2007 18:53:22 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> I do not have the threshold setting enabled, I have explicitely disabled it with: port_.disableReceiveThreshold(); I have also run the same tests with the threshold setting enabled, but they also fail in the same way as described below. So it seems there is a problem with timeout handling on Win32? ________________________________ From: rxtx-bounces at qbang.org on behalf of Trent Jarvi Sent: Sat 3/24/2007 3:12 PM To: RXTX Developers and Users Subject: Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 8312 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20070324/f9e39c9b/attachment-0005.bin From greg.johnson at manchester.ac.uk Sun Mar 25 13:41:36 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Sun, 25 Mar 2007 21:41:36 +0200 Subject: [Rxtx] Mac intel weirdness Message-ID: Hi folks, I'm trying to get rxtx to work on my macbook pro with a USB-serial dongle on it. I am using the 2.1-8 code from the CVS (though it seems to report itself as 2.1-7: makes it difficult to prove to oneself that the changes have 'taken'! - line 4210 in SerialImp.c, line 40 in RXTXVersion.java) I am trying the 2.1-8 because of horrible lock problems in 2.1-7. However, the serialport closure code seems to be broken - it won't close because it believes the (previously opened!) port doesn't exist. Here is what I'm trying: 0. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "false" 1. Open a port Serialport serialport = (SerialPort) commportidentifier.open ("test",100); 2. Talk to a device ... 3. Close port serialport.close(); 4. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "true" - why is this? 5. Try to reopen port Serialport serialport2 = (SerialPort) commportidentifier.open("test", 100); throws PortInUseException. I've dug around a bit in the source, and it seems the SerialPort.close () should call the CommPortIdentifier.internalClosePort() (line 67 of CommPort.java). However, I crash out with the NoSuchPortException when getPortIdentifier is called. Which seems quite weird to me, seeing as it is called on this - which was create just beforehand. Does anyone know how to fix this? Cheers, greg From knute at frazmtn.com Sat Mar 24 10:32:38 2007 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 24 Mar 2007 09:32:38 -0700 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc>, Message-ID: <4604F036.17833.135298@knute.frazmtn.com> > >The behavior of timeout depends upon the setting of the threshold. Do you >have the threshold setting? > This is the same bug I reported last fall. There was a fellow that sent me an email asking if it had been fixed. I told him I didn't think so. He got somebody to write a fix for him but I have not been able to contact him again for the actual changes. The inaccurate timeout and the failure of blocking when no timeouts are set is a serious bug in my humble opinion and renders the software unusable for my applications. I'd really like to have an alternative to the Sun comm api but there just isn't one that I know of. -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Mar 26 16:17:00 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 26 Mar 2007 16:17:00 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> Message-ID: >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. From ra85551 at gmail.com Tue Mar 27 10:18:36 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Tue, 27 Mar 2007 20:18:36 +0400 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Ultimately I found a solution. At first, that wasn't actually the VMWare + WinXP + RXTX issue, that was WinXP + RXTX issue. But on pure XP it sometimes workes, sometimes not, while under VMWare I had never seen my snippet working at all. SimpleSnuV1.java would not help me, because there is only one line I missed, and SimpleSnuV1.java also doesn't contain it! It is as follows: serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_OUT | SerialPort.FLOWCONTROL_RTSCTS_IN); Thank you for your attention. -- Pavel Parkhomenko From griff at op.pl Wed Mar 28 01:28:19 2007 From: griff at op.pl (griff@op.pl) Date: Wed, 28 Mar 2007 09:28:19 +0200 Subject: [Rxtx] No blocking read on Windows. Message-ID: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/5d07d571/attachment-0005.html -------------- next part -------------- Hi, I have problem that InputStram.read() (SerialPort)?returns -1 instead blocking and waiting for data. I found that this problem was ?known in 2005 : ? >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > >> Hi Trent >> >> Thanks for the fast response. >> Here's a Q&D test program for the blocking read on windows that just >> attempts to read one byte, and prints the resulting byte. On my system it >> returns -1, where I expect that it keeps waiting for data. >> >This isn't happening on Linux so the bug is in src/termios.c.? I'll have >something this weekend to fix that. I'm using RXTX 2.1.7r2 and the problem still is here. Im using Windows XP and java 1.5 disableReciveTimeout() and disableReciveTreshhold() dont help. ? best regards ? Piotr Zielniok From Adrien.TOS at ingenico.com Wed Mar 28 01:40:46 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Wed, 28 Mar 2007 09:40:46 +0200 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903E88880@frsnprexc1.usr.ingenico.loc> Looking at the code, it seems there is no support for infinite timeout? And maybe the count++ < 20 condition is breaking out of the loop too early? The only condition to break out of the loop should either be the timeout has expired or the number of requested bytes has been received. -----Message d'origine----- De : rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] De la part de Trent Jarvi Envoy? : mardi 27 mars 2007 00:17 ? : RXTX Developers and Users Objet : Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From j.kenneth.gentle at acm.org Wed Mar 28 06:44:15 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 28 Mar 2007 08:44:15 -0400 Subject: [Rxtx] No blocking read on Windows. In-Reply-To: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> References: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> Message-ID: <200703281844.l2SIiITW028614@qbang.org> Just another "ME TOO!" - I'm seeing this problem on Windows XP, jre for windows XP/Embedded. I cranked receiveTimeout up to Integer.MAX_INT, but it doesn't seem to wait that long At 03:28 2007-03-28, you wrote: >Hi, >I have problem that InputStram.read() (SerialPort) returns -1 >instead blocking and waiting for data. I found that this problem >was known in 2005 : > > >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > > > >> Hi Trent > >> > >> Thanks for the fast response. > >> Here's a Q&D test program for the blocking read on windows that just > >> attempts to read one byte, and prints the resulting byte. On my system it > >> returns -1, where I expect that it keeps waiting for data. > >> > > >This isn't happening on Linux so the bug is in src/termios.c. I'll have > >something this weekend to fix that. > >I'm using RXTX 2.1.7r2 and the problem still is here. >Im using Windows XP and java 1.5 >disableReciveTimeout() and disableReciveTreshhold() dont help. > >best regards > >Piotr Zielniok > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From greg.johnson at manchester.ac.uk Wed Mar 28 14:43:29 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Wed, 28 Mar 2007 22:43:29 +0200 Subject: [Rxtx] Cannot close and reopen serial port Message-ID: <377F9765-7A9D-4CE9-9176-FFB63A2594F0@manchester.ac.uk> Dear all, It appears I cannot close a port properly: SerialPort serialport = portid.open("myprog",100); // do some stuff, all works fine serialport.close(); // all seems fine but... SerialPort sp2 = portid.open("myprog",100); throws PortInUseException. And when I dig into the rxtx code, I find in CommPort.java, in close(): CommPortIdentifier cp = CommPortIdentifier.getPortIdentifier(this); (line 64 or there abouts) but this throws a NoSuchPortException which is caught but ignored (line 74ish). Can anyone suggest how this could happen: a port that was valid, opened, and used, throws a NSPE when it comes to closing it? I'm pulling my (remaining) hair out over this one! Cheers, greg PS And thanks for RXTX - it's great to have! PPS (21.-7. winxp/osx both, java 1.5) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/c28852fc/attachment-0005.html From rxtx at vrijheidslaan.net Fri Mar 30 16:52:50 2007 From: rxtx at vrijheidslaan.net (Rob) Date: Fri, 30 Mar 2007 22:52:50 -0000 Subject: [Rxtx] Cvs Question Message-ID: <61896.80.126.150.87.1175295162.squirrel@webmail.provalue.nl> Hi There, Im trying to get the latest version to work on mac osx. Problem is that i can't checkout version 2.1.8. Probably my fault but can some one please give me the alternative commands for: [user at myhost]$ export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot [user at myhost]$ cvs login Thanx, Rob From ra85551 at gmail.com Thu Mar 1 03:47:06 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Thu, 1 Mar 2007 13:47:06 +0300 Subject: [Rxtx] enableReceiveTimeout() issue Message-ID: Hello, world! I found a limitation of 16300 ms for CommPort's enableReceiveTimeout() method, while in original javax.comm docs there are no any references to that. Is that a bug or feature? I actually need longer timeouts sometimees. -- Pavel Parkhomenko From lyon at docjava.com Thu Mar 1 07:54:17 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 01 Mar 2007 09:54:17 -0500 Subject: [Rxtx] parametric singleton design pattern In-Reply-To: References: <22d55aea0702081207q5e7f6785l352d498d6f5f9fb1@mail.gmail.com> <22d55aea0702100034o3bcf42f3j1d1a6257029a67b0@mail.gmail.com> Message-ID: Hi All, I have been thinking about the use of a design pattern to cache resources that are consumed by processes. Toward that end, I have arrived at a parametric singleton design pattern, which I mentioned on this list some time ago. The idea has been published at: http://www.jot.fm/issues/issue_2007_03/column2 I can't help but think that there should be an API available for dealing with the tracking of serial port usage. Perhaps it is a kind of resource manager called the: SerialPortManager basic prototypes already exist in this vain. See, for example: http://www.ce.rit.edu/research/projects/2005_fall/rt_poolsystem/doc/PoolMon/SerialPortManager.html http://www.eventhelix.com/RealtimeMantra/PatternCatalog/serial_port_design_pattern.htm And others shown by a google search on "SerialPortManager" Cheers! - Doug From Eric.Arseneau at sun.com Thu Mar 1 10:15:03 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:15:03 -0800 Subject: [Rxtx] Any known Java 6 issues with RXTX 2.1-7r2 ? Message-ID: <45E70A17.1060206@sun.com> I just did a test on a recent build of Solaris 11 x86 and it seems that I can connect to my serial device fine when Java 5 is the default, but when Java 6 is the default, no go. Any information ? From Eric.Arseneau at sun.com Thu Mar 1 10:19:58 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:19:58 -0800 Subject: [Rxtx] Mac OS X and missing data Message-ID: <45E70B3E.7040908@sun.com> We have a device which is USB based but presents itself as a serial port to a machine. On my MacBook Pro I can get excellent throughput if I get my device to send data as quickly as possible. On the desktop side, if I do an type of disk IO to log the data I get, I end up with some missing data at some point. I hooked up a USB analyzer and did confirm that all the data is sent as expected to the desktop from the device. I found a work around for this, buffer the data in memory and only write the data out when I've received it all. However, when the same code and same device is attempted on a co-workers MacBook Pro (same hardware specs), I get errors and must slow down dramatically the device side's sending of data. Any ideas/recommendations on what I can do to get rid of this error ? From what I can tell, it seems that RXTX is not able to wake up to the interrupts coming in indicating data is ready, quickly enough, is there anything I can do ? From chinkaiw at hotmail.com Fri Mar 2 00:57:43 2007 From: chinkaiw at hotmail.com (Wang Chinkai) Date: Fri, 02 Mar 2007 07:57:43 +0000 Subject: [Rxtx] dynamic detect rs232 port Message-ID: Hi all I have a question about detecting rs232 port dynamicly. I have to aceess some port and detect rs232 port at the same time. Some usb device simulates rs232 port , and I can not know what the port name it gets until it connects,so I have to detect it dynamic,but I have to access another rs232 device at the same time. I found a problem. If I use CommPortIdentifier.getPortIdentifiers() to get new port list , and the other rs232 access function will not close port correctly. So , How can I solve it . Thanks. _________________________________________________________________ ?? 2GB ???? Windows Live Mail ????????????? http://ideas.live.com/programpage.aspx?versionid=5d21c51a-b161-4314-9b0e-4911fb2b2e6d From eu259473 at tele2.it Fri Mar 2 06:16:40 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 02 Mar 2007 14:16:40 +0100 Subject: [Rxtx] rxtx on HP tru 64 unix Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070302/706c7a70/attachment-0006.html From tjarvi at qbang.org Fri Mar 2 08:39:33 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 08:39:33 -0700 (MST) Subject: [Rxtx] rxtx on HP tru 64 unix In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, "Giuseppe Marchese" wrote: > Hi > > I try to install rxtx on hp tru 64 but make fails, > There are somebody that do the same and work. > > > Sorry for may english! > > Hi Giuseppe Could you provide a log of the failure? script ./configure make # use gnu make exit The information will be in the typescript created. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 2 19:56:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 19:56:52 -0700 (MST) Subject: [Rxtx] dynamic detect rs232 port In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, Wang Chinkai wrote: > Hi all > > I have a question about detecting rs232 port dynamicly. > > I have to aceess some port and detect rs232 port at the same time. > Some usb device simulates rs232 port , and I can not know > what the port name it gets until it connects,so I have to detect it > dynamic,but I have to access > another rs232 device at the same time. > > I found a problem. Hi Wang This is a known problem. The code is braindead there. In fact there needs to be events even in a rudamentary way when you add a usb dongle. I'm burried in tasks not far from rxtx but not in rxtx. I can't get to the problem but we would accept patches if you dig into it. [I'm getting to the license question earlier too; I don't have another 10%] -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Fri Mar 2 23:19:01 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 01:19:01 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Hi, Under ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable USB -> serial converter(using virtual com port drivers), with using example code pretty much straight out of http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port opens fine, enumerations all work, etc. My application calls for a large amount of data to be transferred in a short amount of time at 2,000,000 baud. My hardware sends approximately 15,232 bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL converter work fine, and the application works using C++. In C++, I do a hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); to open the port, and a boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); to read the port. The variable buffer fills with the 15238 bytes, and returns. If I do a resultz = is.read(cbuf,0,15238); in java with RXTX where is = new BufferedReader(new InputStreamReader(port.getInputStream())); and where resultz is an int, and cbuf is a char [] cbuf, resultz gets EXACTLY 3968 bytes the first time called. If I call it multiple times, I get roughly 11k total(less than what is sent), never more than the 3968 bytes per is.read() call. My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 bytes. I've played with inputbuffersize, receive threshold, receivetimeout, and so on. The FTDI virtual com port drivers that I'm using are rock solid, and have had zero problems with them using a variety of applications, some of my own, some professionally written, etc. No flow control is used anyplace, no RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. No exceptions are being thrown. What am I doing wrong, and what I can adjust to receive the full 15k bytes in one single read? Thanks! Keith From Eric.Arseneau at sun.com Fri Mar 2 23:32:07 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Fri, 02 Mar 2007 22:32:07 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <45E91667.20501@sun.com> This is the same type of thing that is happening to me on Mac OS X and does not seem to behave the same on different machines. I posted a day or two ago on this with subject "Mac OS X and missing data". Would love to hear if there is a solution to this :) From tjarvi at qbang.org Sat Mar 3 10:54:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 10:54:17 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > Hi, > > Under > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable > USB -> serial converter(using virtual com port drivers), with using example > code pretty much straight out of > http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port > opens fine, enumerations all work, etc. > > My application calls for a large amount of data to be transferred in a short > amount of time at 2,000,000 baud. My hardware sends approximately 15,232 > bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL > converter work fine, and the application works using C++. > > In C++, I do a > > hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, > OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); > > to open the port, and a > > boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); > > to read the port. > > The variable buffer fills with the 15238 bytes, and returns. > > If I do a > > resultz = is.read(cbuf,0,15238); in java with RXTX > > where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > > and where resultz is an int, and cbuf is a char [] cbuf, resultz gets > EXACTLY 3968 bytes the first time called. If I call it multiple times, I get > roughly 11k total(less than what is sent), never more than the 3968 bytes > per is.read() call. > > My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 > bytes. > > I've played with inputbuffersize, receive threshold, receivetimeout, and so > on. The FTDI virtual com port drivers that I'm using are rock solid, and > have had zero problems with them using a variety of applications, some of my > own, some professionally written, etc. No flow control is used anyplace, no > RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. > > No exceptions are being thrown. > > What am I doing wrong, and what I can adjust to receive the full 15k bytes > in one single read? > > Thanks! > Hi Keith I would expect a 20 meg application is going to have different behavior with the OS than a smaller application with respect to the kernel memory managment, schedualing, ... Something subtle could be causing problems. With respect to the recieve timeout and threshold, if you set the timeout to zero and the threshold to the size of data you expect, read should not return until it get that data. You may try with a stand alone application that tests just that with the C/C++ API. If the read is returning with less data when tested for short reads, you have found a bug in the device driver more than likely. The USB dongle vendor would probably be interested in knowing about this. As mentioned, these devices are getting very good; almost bug free. I suspect you found a bug though if you did use the threshold and timeout properly. The missing data is typical when not using flow control. When the OS buffering fills, the hardware will start dropping bytes. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:38:52 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:38:52 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> update: I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now instead of 3968. This makes sense. 128 bytes of overhead + 3968 bytes of data = 4096 transfer size 32 bytes of overhead + 992 bytes of data = 1024 transfer size. 1/4 the data = 1/4 the overhead. I rearranged my reading like so: resultz = is.read(cbuf,0,3968); resultz = is.read(cbuf,3968,3968); resultz = is.read(cbuf,7936,3968); while (!(is.ready())); // wait for ready resultz = is.read(cbuf,11904,3334); and this grabs 15,238 bytes total. BUT, I still have the quandry of the screwed up multi-bytes. I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. Approx 8% of the data. The bad bytes always seem to take the flavor of 0x2018, 0x2019, x2022, x2030, x201d. Are these maybe errors and I don't know what they enumerate to? I still can't believe some other layer isn't handling putting those bytes together all in one stream for me. Thanks Keith ----- Original Message ----- From: "Keith" To: "Bob Jacobsen" ; "RXTX Developers and Users" Sent: Saturday, March 03, 2007 11:26 AM Subject: Re: [Rxtx] is.read() only returning 3968 bytes > Bob, > > > Interesting numerical coincidence is that (max USB transfer) - (what > > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > > needed to transfer that much data. > > I was thinking along the same lines. I don't know USB well, but I do know > that those numbers were close enough to warrant investigating the > relationship between them. > > > I think what you're seeing is the internal buffering of the USB data > > stream. You'll need some form of higher-level buffering to smooth > > that out. > > Shouldn't the InputStreamReader() and BufferedReader() provide this type of > buffering? Isn't that the idea behind those? > > > All hypotheses need to be tested. In this case, a test would be to > > check for missing data. If this idea is right, you'll get _all_ the > > data, but you won't be missing characters. > > I did start looking at the data. -- I'm getting weird results. > > I tried this: > > loopzz = 0; > > for (looptwo = 0; looptwo < 100000; looptwo++) { > while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > > }} > > So I'm reading one character at a time. The good news is that loopzz is > exactly 15238 at the end of the routine, which is perfectly correct. I > picked looptwo value out of thin air. > > The weird results come in terms of the values, the data isn't correct at > least in one case. Look here: > > 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > > This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). > But the 0x89 was replaced by 0x2030. Why the heck would the returned value > be 0x2030?? Why is the returned byte completely out of range? Why the > multibyte return? > > From InputStream in the API: > > read > public abstract int read() > throws IOExceptionReads the next byte of data from the > input stream. The value byte is returned as an int in the range 0 to 255. If > no byte is available because the end of the stream has been reached, the > value -1 is returned. This method blocks until input data is available, the > end of the stream is detected, or an exception is thrown. > Value should be 0-255. > > > In my application time is really critical, reading 1 byte at a time is > probably not going to work. > > Thanks Eric & Bob for looking at this. > > Keith > From tjarvi at qbang.org Sat Mar 3 12:52:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 12:52:27 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > update: > > I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now > instead of 3968. > > This makes sense. > > 128 bytes of overhead + 3968 bytes of data = 4096 transfer size > 32 bytes of overhead + 992 bytes of data = 1024 transfer size. > > 1/4 the data = 1/4 the overhead. > > I rearranged my reading like so: > > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. > Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? > > I still can't believe some other layer isn't handling putting those bytes > together all in one stream for me. > The layer for this in Serial land is flow control. Software and hardware flow control prevent the overruns you observe. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:54:41 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:54:41 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <001a01c75dcd$c8802a70$6600a8c0@jbh757ktruws7g> Trent, Thanks for taking the time to reply. > I would expect a 20 meg application is going to have different behavior > with the OS than a smaller application with respect to the kernel memory > managment, schedualing, ... Something subtle could be causing problems. Well, at least I know the VCP drivers, the OS, etc can handle 2mbps reliably. Without hiccuping or dropping bytes. The C++ code works reliably without flow control. > The missing data is typical when not using flow control. When the OS > buffering fills, the hardware will start dropping bytes. I'm actually not getting MISSING data, I'm getting CORRUPTED data. If you look at my most recent post, I'm getting these bad bytes in place of the correct values: 0x2018, 0x2019, x2022, x2030, x201d. Why would is.read() return values not in the range of 0-255 ? Thanks. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 08:59:14 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 07:59:14 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: At 1:19 AM -0500 3/3/07, Keith wrote: >If I do a > >resultz = is.read(cbuf,0,15238); in java with RXTX > >where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > >and where resultz is an int, and cbuf is a char [] cbuf, resultz gets >EXACTLY 3968 bytes the first time called. If I call it multiple times, I get >roughly 11k total(less than what is sent), never more than the 3968 bytes >per is.read() call. > >My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 >bytes. Interesting numerical coincidence is that (max USB transfer) - (what you get) = 4096-3968 = 128 bytes is (almost) the size of the headers needed to transfer that much data. I think what you're seeing is the internal buffering of the USB data stream. You'll need some form of higher-level buffering to smooth that out. All hypotheses need to be tested. In this case, a test would be to check for missing data. If this idea is right, you'll get _all_ the data, but you won't be missing characters. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 09:26:14 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 11:26:14 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Bob, > Interesting numerical coincidence is that (max USB transfer) - (what > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > needed to transfer that much data. I was thinking along the same lines. I don't know USB well, but I do know that those numbers were close enough to warrant investigating the relationship between them. > I think what you're seeing is the internal buffering of the USB data > stream. You'll need some form of higher-level buffering to smooth > that out. Shouldn't the InputStreamReader() and BufferedReader() provide this type of buffering? Isn't that the idea behind those? > All hypotheses need to be tested. In this case, a test would be to > check for missing data. If this idea is right, you'll get _all_ the > data, but you won't be missing characters. I did start looking at the data. -- I'm getting weird results. I tried this: loopzz = 0; for (looptwo = 0; looptwo < 100000; looptwo++) { while (is.ready()) { cbuf[loopzz] = (char) is.read(); loopzz++; }} So I'm reading one character at a time. The good news is that loopzz is exactly 15238 at the end of the routine, which is perfectly correct. I picked looptwo value out of thin air. The weird results come in terms of the values, the data isn't correct at least in one case. Look here: 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). But the 0x89 was replaced by 0x2030. Why the heck would the returned value be 0x2030?? Why is the returned byte completely out of range? Why the multibyte return? >From InputStream in the API: read public abstract int read() throws IOExceptionReads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown. Value should be 0-255. In my application time is really critical, reading 1 byte at a time is probably not going to work. Thanks Eric & Bob for looking at this. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 14:44:50 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 13:44:50 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: Java's "char" type is Unicode. I think what you're seeing is a bug in the byte -> Unicode translation. 0x2018, 0x2019 are the curly open and close quotes. There used to be (and might still be) bugs in the conversion of these in a couple of libc versions. Some of the ASCII -> ISO and ISO -> ASCII routines were a little over-ambitious with respect to handling the open and close quotes, and tried to convert them to the "curly" form inappropriately. Try _not_ casting it to char. Bob At 11:26 AM -0500 3/3/07, Keith wrote: >Bob, > >> Interesting numerical coincidence is that (max USB transfer) - (what >> you get) = 4096-3968 = 128 bytes is (almost) the size of the headers >> needed to transfer that much data. > >I was thinking along the same lines. I don't know USB well, but I do know >that those numbers were close enough to warrant investigating the >relationship between them. > >> I think what you're seeing is the internal buffering of the USB data >> stream. You'll need some form of higher-level buffering to smooth >> that out. > >Shouldn't the InputStreamReader() and BufferedReader() provide this type of >buffering? Isn't that the idea behind those? > >> All hypotheses need to be tested. In this case, a test would be to >> check for missing data. If this idea is right, you'll get _all_ the >> data, but you won't be missing characters. > >I did start looking at the data. -- I'm getting weird results. > >I tried this: > >loopzz = 0; > >for (looptwo = 0; looptwo < 100000; looptwo++) { >while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > >}} > >So I'm reading one character at a time. The good news is that loopzz is >exactly 15238 at the end of the routine, which is perfectly correct. I >picked looptwo value out of thin air. > >The weird results come in terms of the values, the data isn't correct at >least in one case. Look here: > >0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > >This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). >But the 0x89 was replaced by 0x2030. Why the heck would the returned value >be 0x2030?? Why is the returned byte completely out of range? Why the >multibyte return? > >>From InputStream in the API: > >read >public abstract int read() > throws IOExceptionReads the next byte of data from the >input stream. The value byte is returned as an int in the range 0 to 255. If >no byte is available because the end of the stream has been reached, the >value -1 is returned. This method blocks until input data is available, the >end of the stream is detected, or an exception is thrown. >Value should be 0-255. > > >In my application time is really critical, reading 1 byte at a time is >probably not going to work. > >Thanks Eric & Bob for looking at this. > >Keith > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 15:10:11 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 17:10:11 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Bob said ..... > Java's "char" type is Unicode. I think what you're seeing is a bug > in the byte -> Unicode translation. Bob -- I think you hit the nail on the head. I was just coming to the same realization here. I knew that something funny was going on because the same bytes always got "corrupted." I'm pretty sure its in the InputStreamReader() functionality where the conversion junk is happening. Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. I don't know if simply changing the cast is going to work. Since the conversion is happening upstream (pun intended), I don't think my cast is doing this. Also I think the compiler forced me to use the cast. I'm still playing around, and I'll report back once I nail it down. Thanks!! Keith From tjarvi at qbang.org Sat Mar 3 15:59:46 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 15:59:46 -0700 (MST) Subject: [Rxtx] Win64 rxtx Testers? Message-ID: I have compiled win64 binaries of rxtx. Are there any users interested in testing them? If so, I'll look into putting them on the web site. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Mar 3 15:35:06 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 14:35:06 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: Because of this and similar problems, JMRI does all it's serial IO using +only+ byte values. It's a but of a pain, as Java wants to go to char and int types a little too aggressively, but it does solve the "uncontrolled conversions" problems. Bob At 5:10 PM -0500 3/3/07, Keith wrote: >Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > >Bob -- I think you hit the nail on the head. > >I was just coming to the same realization here. I knew that something funny >was going on because the same bytes always got "corrupted." > >I'm pretty sure its in the InputStreamReader() functionality where the >conversion junk is happening. > >Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > >I don't know if simply changing the cast is going to work. Since the >conversion is happening upstream (pun intended), I don't think my cast is >doing this. Also I think the compiler forced me to use the cast. -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mark at mdsh.com Sun Mar 4 11:01:33 2007 From: mark at mdsh.com (Mark Himsley) Date: Sun, 04 Mar 2007 18:01:33 +0000 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: <5C01AC72C200388815C04982@bedroom.mdsh.local> On 03 March 2007 14:38 -0500 Keith wrote: > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT > consistent. Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? It looks like you need to use DataInputStream and DataOutputStream. -- Mark Himsley From tjarvi at qbang.org Sun Mar 4 11:35:08 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 11:35:08 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" > > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > > * Line #21 - Not sure if you need a (TM) mark for > the term "Sun" > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > OK. I'm going through this today. Some groups ask if rxtx could be under their license also. I think this is a good example of why I resist multiple licenses and focus on why the current license may not be usable by them. The RXTX project is a convergence of hobby and commercial interests. I happen to do both right now. The problem with licensing is we have to stay on top of them as they change. Clearly, adding more licenses will not make this easier. I'm acting as the hobby person today. RXTX always favors the hobby people. But as we move forward, I'm going to need to bring this to lawyers at work and explain to them what is going on. Others here may have to do this also. I don't anticipate problems or unexpected changes. The goal is a consistant, comprehendable and usable license as close to what we have now as possible. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 14:52:10 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 14:52:10 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (1/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: I'm breaking this into two parts. I expect the second part will need more attention. Comments first, then the changed material below. On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > Thanks > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. OK. RXTX for consitent use. java should not be capitalized because it does not only mean Sun [TM] Java [TM]. An example of this not meaning Java is when people use RXTX with GCJ. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". There are not any contributors that are in all of RXTX yet but I did update the comment to try to reflect the current situation without making it a nightmare to maintain. I looked to see how the Linux kernel does it as a reference point. > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" The URL can be problematic. I have done so below with a time reference. GNU does not provide version information in their URLS. I picture this being a problem when the version 3 comes out. > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > This will be corrected when the copy is updated to the version linked below. ---------------- begin proposed material involved -------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. ----------------- end proposed material involved -------------------- I'll be looking at the linking issue again next. That should be all that remains other than including the 2.1 version. Let me know if you have problems with anything here. I do not want to dilute the material I post next with these housekeeping tasks. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 16:08:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 16:08:36 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: For those that are wondering what is going on here, this next bit is the meat of the changes. We agreed a long time ago to put this disclaimer in. We did a so so job. It was in rxtx 2.0, not well written, ... So some groups using rxtx that would like to ship rxtx so users don't need to download, install, go to the mail-list to find why it failed, ... Then their legal teams tell them section 5 paragraph 2 is a show stopper. That was never the intent. Now going through what remains... > and might need a (TM) suffix to make Sun happy. Added disclaimer at the ended 'all trademarks belong...' > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. OK. As you can see I was trying to adjust GNU text there for the LGPL. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. used dynamically linked terminology. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". I tried to address this more upfront with an intent statement. Let me know if you have problems with it. I also tried to make it a little more clear what was derived from the GNU solution by moving the link location closer to GNU's suggestion. > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > Thats the intent. Here is the combined fixes. Note that only the material in /*-- --*/ is being touched. The new GPL license is there but unmodified. ------------------------ begin proposed new license ------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. | | An executable that contains no derivative of any portion of RXTX, but | is designed to work with RXTX by being dynamically linked with it, | is considered a "work that uses the Library" subject to the terms and | conditions of the GNU Lesser General Public License. | | The following has been added to the RXTX License to remove | any confusion about linking to RXTX. We want to allow in part what | section 5, paragraph 2 of the LGPL does not permit in the special | case of linking over a controlled interface. The intent is to add a | Java Specification Request or standards body defined interface in the | future as another exception but one is not currently available. | | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface | | As a special exception, the copyright holders of RXTX give you | permission to link RXTX with independent modules that communicate with | RXTX solely through the Sun Microsytems CommAPI interface version 2, | regardless of the license terms of these independent modules, and to copy | and distribute the resulting combined work under terms of your choice, | provided that every copy of the combined work is accompanied by a complete | copy of the source code of RXTX (the version of RXTX used to produce the | combined work), being distributed under the terms of the GNU Lesser General | Public License plus this exception. An independent module is a | module which is not derived from or based on RXTX. | | Note that people who make modified versions of RXTX are not obligated | to grant this special exception for their modified versions; it is | their choice whether to do so. The GNU Lesser General Public License | gives permission to release a modified version without this exception; this | exception also makes it possible to release a modified version which | carries forward this exception. | | You should have received a copy of the GNU Lesser General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA | All trademarks belong to their respective owners. --------------------------------------------------------------------------*/ The original GNU Lesser General Public License Follows. GNU LESSER GENERAL PUBLIC LICENSE Version 2.1, February 1999 Copyright (C) 1991, 1999 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. [This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence the version number 2.1.] Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This license, the Lesser General Public License, applies to some specially designated software packages--typically libraries--of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below. When we speak of free software, we are referring to freedom of use, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish); that you receive source code or can get it if you want it; that you can change the software and use pieces of it in new free programs; and that you are informed that you can do these things. To protect your rights, we need to make restrictions that forbid distributors to deny you these rights or to ask you to surrender these rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library or if you modify it. For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights. We protect your rights with a two-step method: (1) we copyright the library, and (2) we offer you this license, which gives you legal permission to copy, distribute and/or modify the library. To protect each distributor, we want to make it very clear that there is no warranty for the free library. Also, if the library is modified by someone else and passed on, the recipients should know that what they have is not the original version, so that the original author's reputation will not be affected by problems that might be introduced by others. Finally, software patents pose a constant threat to the existence of any free program. We wish to make sure that a company cannot effectively restrict the users of a free program by obtaining a restrictive license from a patent holder. Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license. Most GNU software, including some libraries, is covered by the ordinary GNU General Public License. This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs. When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library. We call this license the "Lesser" General Public License because it does Less to protect the user's freedom than the ordinary General Public License. It also provides other free software developers Less of an advantage over competing non-free programs. These disadvantages are the reason we use the ordinary General Public License for many libraries. However, the Lesser license provides advantages in certain special circumstances. For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License. In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software. For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU operating system, as well as its variant, the GNU/Linux operating system. Although the Lesser General Public License is Less protective of the users' freedom, it does ensure that the user of a program that is linked with the Library has the freedom and the wherewithal to run that program using a modified version of the Library. The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, whereas the latter must be combined with the library in order to run. GNU LESSER GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License Agreement applies to any software library or other program which contains a notice placed by the copyright holder or other authorized party saying it may be distributed under the terms of this Lesser General Public License (also called "this License"). Each licensee is addressed as "you". A "library" means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables. The "Library", below, refers to any such software library or work which has been distributed under these terms. A "work based on the Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term "modification".) "Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library. Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does. 1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) The modified work must itself be a software library. b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change. c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License. d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful. (For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library. In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. 4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange. If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code. 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables. When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law. If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.) Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself. 6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications. You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things: a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.) b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. c) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution. d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place. e) Verify that the user has already received a copy of these materials or that you have already sent this user a copy. For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute. 7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things: a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above. b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work. 8. You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 9. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Library (or any work based on the Library), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Library or works based on it. 10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties with this License. 11. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply, and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 12. If the distribution and/or use of the Library is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Library under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 13. The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation. 14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Libraries If you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the ordinary General Public License). To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Also add information on how to contact you by electronic and paper mail. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the library, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the library `Frob' (a library for tweaking knobs) written by James Random Hacker. , 1 April 1990 Ty Coon, President of Vice That's all there is to it! ------------------------ end of proposed license ------------------ -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sun Mar 4 16:26:04 2007 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 04 Mar 2007 17:26:04 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <45EB558C.3010609@cox.net> Bob Jacobsen wrote: > Because of this and similar problems, JMRI does all it's serial IO > using +only+ byte values. It's a but of a pain, as Java wants to go > to char and int types a little too aggressively, but it does solve > the "uncontrolled conversions" problems. Anytime that you are reading bytes of data that is not printable, unicode text, in Java, you really need to stay away from the Readers. Use input stream only, or you will see unicode valued byte groups converted to unicode "char" values. Gregg Wonderly From joachim at buechse.de Mon Mar 5 04:23:48 2007 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 5 Mar 2007 12:23:48 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> The behaviour is exactly what you asked for in you code. is = new BufferedReader(new InputStreamReader(port.getInputStream())); Readers return Text (ie unicode chars) not bytes. You instantiate the InputStreamReader without saying which charset you want, which means "platform default". As this is on Windows, it will convert Windows characters to equivalent unicode characters. If you want to read bytes, read bytes not Text. Reading bytes is done with InputStream and BufferedInputStream. BTW: The InputStream and Reader methods that read arrays are not guarenteed to fill up the array. You always have to check what you really got, and advance your index accordingly. A typical "read up to 32k" method looks like this: InputStream is= ... // -- determine the max buffer size int len= is.available(); if (len == 0) { len= 32 * 1024; } // -- read all available data byte[] buffer= new byte[len]; int pos= 0; int read; do { read= is.read(buffer, pos, buffer.length - pos); pos= pos + read; } while (read != -1 && pos < buffer.length); Best regards, Joachim --- Joachim B?chse Phone: +41 44 500 2604 Buechse Consulting Hadlaubsteig 2 CH-8006 Z?rich On 03.03.2007, at 23:10, Keith wrote: > Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > > Bob -- I think you hit the nail on the head. > > I was just coming to the same realization here. I knew that > something funny > was going on because the same bytes always got "corrupted." > > I'm pretty sure its in the InputStreamReader() functionality where the > conversion junk is happening. > > Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > > I don't know if simply changing the cast is going to work. Since the > conversion is happening upstream (pun intended), I don't think my > cast is > doing this. Also I think the compiler forced me to use the cast. > > I'm still playing around, and I'll report back once I nail it down. > > Thanks!! > > Keith > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Mon Mar 5 07:25:46 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 05 Mar 2007 08:25:46 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> Message-ID: <45EC286A.8060608@cox.net> Joachim Buechse wrote: > BTW: The InputStream and Reader methods that read arrays are not > guarenteed to fill up the array. You always have to check what you > really got, and advance your index accordingly. A typical "read up to > 32k" method looks like this: > > InputStream is= ... > // -- determine the max buffer size > int len= is.available(); > if (len == 0) { > len= 32 * 1024; > } > // -- read all available data > byte[] buffer= new byte[len]; > int pos= 0; > int read; > do { > read= is.read(buffer, pos, buffer.length - pos); > pos= pos + read; > } while (read != -1 && pos < buffer.length); > My preferred structure is. byte arr[ len ]; int cnt; int off = 0; while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { off += cnt; } This keeps you from adding -1 to pos when the read returns -1. It also skips out when the read is 0 bytes which, is not a described EOF in InputStream java docs, but is a condition I want to be aware of. Gregg Wonderly From joachim at buechse.de Tue Mar 6 02:52:58 2007 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 6 Mar 2007 10:52:58 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <45EC286A.8060608@cox.net> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: The code I copied was from a file resource reader, it shouldn't really be applied to networking/external IO code. Mea culpa. However aborting when you get 0 from read is not always what you want either (you kind of indicated that already). Some unix java implementations will return 0 if the kernel read was aborted with EINTER, which is rarely the point where you want to abort your read - at least not without further checks. A "complete" solution always depends on the events you need to handle and the time the total read could take in reality. In some cases it's worth checking Thread.isInterrupted() in the loop, some code re-loops on 0 but only a limited number of times, some check a total timeout limit, etc... Best regards, Joachim On 05.03.2007, at 15:25, Gregg Wonderly wrote: > My preferred structure is. > > byte arr[ len ]; > int cnt; > int off = 0; > while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { > off += cnt; > } > > This keeps you from adding -1 to pos when the read returns -1. It > also skips > out when the read is 0 bytes which, is not a described EOF in > InputStream java > docs, but is a condition I want to be aware of. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Mar 6 14:47:44 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 Mar 2007 14:47:44 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: Just FYI, rxtx will usually not break out on EINTER. The code in the native library usually does something close to this: do { read(...) } while ( !done && errno==EINTR ); Obviously there is a little more involved but it will retry on EINTER if not done. On Tue, 6 Mar 2007, Joachim Buechse wrote: > The code I copied was from a file resource reader, it shouldn't > really be applied to networking/external IO code. Mea culpa. > > However aborting when you get 0 from read is not always what you want > either (you kind of indicated that already). Some unix java > implementations will return 0 if the kernel read was aborted with > EINTER, which is rarely the point where you want to abort your read - > at least not without further checks. A "complete" solution always > depends on the events you need to handle and the time the total read > could take in reality. In some cases it's worth checking > Thread.isInterrupted() in the loop, some code re-loops on 0 but only > a limited number of times, some check a total timeout limit, etc... > > Best regards, > Joachim > > On 05.03.2007, at 15:25, Gregg Wonderly wrote: >> My preferred structure is. >> >> byte arr[ len ]; >> int cnt; >> int off = 0; >> while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { >> off += cnt; >> } >> >> This keeps you from adding -1 to pos when the read returns -1. It >> also skips >> out when the read is 0 bytes which, is not a described EOF in >> InputStream java >> docs, but is a condition I want to be aware of. >> >> Gregg Wonderly >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 gjhanna at gmail.com Thu Mar 8 13:42:52 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Fri, 9 Mar 2007 09:42:52 +1300 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? Message-ID: I've just struck an issue using rxtx in a multi-threaded environment: If I have 3 threads trying to open *the same* comm-port I get a deadlock in CommPortIdentifier.open If I have just 2, it works fine - I get a PortInUseException which is nice and I can handle it. The 3 thread->deadlock thing is causing me issues. (Sample code below). This is from the java thread-dump Found one Java-level deadlock: ============================= "Thread-2": waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object ), which is held by "Thread-1" "Thread-1": waiting to lock monitor 0x0003e9cc (object 0x2450e108, a gnu.io.CommPortIdentifier), which is held by "Thread-2" Java stack information for the threads listed above: =================================================== "Thread-2": at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:329) - waiting to lock <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) "Thread-1": at java.lang.Object.wait(Native Method) - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) - locked <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) (Apart from this, rxtx is working fantastically for us). I'm thinking I'll have to implement some sort of locking mechanism that *doesn't* use java synchronization to prevent this situation. (Which doesn't sound like a good idea to me). Any ideas? Thanks, Greg Hanna ============= RXTXLockTest.java ======================================== import gnu.io.CommPort; import gnu.io.CommPortIdentifier; /** * @author Greg Hanna * Minimal code to create a deadlock with rxtx in multithreaded open */ public class RXTXLockTest { public static void main(String[] args) { try { CommPortIdentifier cpiCom1 = CommPortIdentifier.getPortIdentifier ("COM14"); OpenThread t1 = new OpenThread (" one ", cpiCom1); OpenThread t2 = new OpenThread (" two ", cpiCom1); OpenThread t3 = new OpenThread (" 003 ", cpiCom1); t1.start(); t2.start(); t3.start(); // comment this out and it runs with (expected) PortInUseException } catch (Exception e) { e.printStackTrace(); } } } class OpenThread extends Thread { String name; CommPortIdentifier cpi; CommPort cp; public OpenThread (String name, CommPortIdentifier cpi) { this.name = name; this.cpi = cpi; System.out.println (System.currentTimeMillis() + name + " thread created"); } public void run () { try { System.out.println (System.currentTimeMillis() + name + " opening"); cp = cpi.open(name, 2000); System.out.println (System.currentTimeMillis() + name + " opened - sleeping"); sleep (2000); // do the serial comms with the device. System.out.println (System.currentTimeMillis() + name + " slept - closing"); cp.close(); System.out.println (System.currentTimeMillis() + name + " closed - exiting"); } catch (Exception e) { System.out.println ("Error in thread: " + name ); e.printStackTrace(); } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070308/d9a163c5/attachment-0006.html From eu259473 at tele2.it Fri Mar 9 02:46:20 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 09 Mar 2007 10:46:20 +0100 Subject: [Rxtx] rxtx: tru64 unix make fails Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070309/3b654523/attachment-0006.html From lyon at docjava.com Fri Mar 9 03:58:32 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 Mar 2007 05:58:32 -0500 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi All, The deadlock issue is one that I have been thinking about for some time now. It seems to me that we need a resource manager that enables assignment to a known process. The one thing that seems important about serial ports is that two applications should not use the same serial port at the same time. When this happens, it throws an exception. OK. The exception is a response to a lock condition that arises from an unavailable resource. An abstract implementation (not born of native methods) might assign a serial port to an application, until the application releases it (or is forced to release it by some kill mechanism). Some resources (like a registry) can be reused. But others, like the serial port, cannot. In the case of the serial port, we would like, I think, to have the flyweight design pattern without sharing and with object assignment tracking. A means of breaking deadlock (like a leasing mechanism) seems very useful, to me. My guess is that we can serialize the state of the Parametric Singleton Pattern (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) into the Preferences of the System. Preferences.systemRoot() might help with that. When a resource is checked out, the lease time and owner are listed. A thread that does this can be killed, but applications outside of Java are problematic. There is a compelling problem here. It is not just serial ports. Sound cards, cameras, microphones, files, tape drives, etc. All are consumed resources that are assigned to an application (or user) and deprive other applications, or users, from use. What, if anything, should we do? At present we throw PortInUseExceptions. Is that it? Can we do better? OK, the port is in use. Now what? Do I have to be root to go remove lock files and kill applications? Is there a better way? Thanks! - Doug >I've just struck an issue using rxtx in a multi-threaded environment: > >If I have 3 threads trying to open *the same* >comm-port I get a deadlock in >CommPortIdentifier.open >If I have just 2, it works fine - I get a >PortInUseException which is nice and I can >handle it. > >The 3 thread->deadlock thing is causing me issues. >(Sample code below). > >This is from the java thread-dump > >Found one Java-level deadlock: >============================= >"Thread-2": > waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), > which is held by "Thread-1" >"Thread-1": > waiting to lock monitor 0x0003e9cc (object >0x2450e108, a gnu.io.CommPortIdentifier ), > which is held by "Thread-2" > >Java stack information for the threads listed above: >=================================================== >"Thread-2": > at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) > - waiting to lock <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) >"Thread-1": > at java.lang.Object.wait(Native Method) > - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) > - locked <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) > > >(Apart from this, rxtx is working fantastically for us). > >I'm thinking I'll have to implement some sort of >locking mechanism that *doesn't* use java >synchronization to prevent this situation. >(Which doesn't sound like a good idea to me). > >Any ideas? > >Thanks, > >Greg Hanna > >============= RXTXLockTest.java ======================================== > >import gnu.io.CommPort; >import gnu.io.CommPortIdentifier; > >/** > * @author Greg Hanna > * Minimal code to create a deadlock with rxtx in multithreaded open > */ >public class RXTXLockTest { > ? > ?public static void main(String[] args) { > ?try { > ?CommPortIdentifier cpiCom1 = >CommPortIdentifier.getPortIdentifier ("COM14"); > ?OpenThread t1 = new OpenThread (" one ", cpiCom1); > ?OpenThread t2 = new OpenThread (" two ", cpiCom1); > ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); > ?t1.start(); > ?t2.start(); > ?t3.start(); // comment this out >and it runs with (expected) PortInUseException > ?} catch (Exception e) { > ?e.printStackTrace(); > ?} > ?} >} > >class OpenThread extends Thread { > ?String name; > ?CommPortIdentifier cpi; > ?CommPort cp; > ?public OpenThread (String name, CommPortIdentifier cpi) { > ? this.name = name; > ?this.cpi = cpi; > ?System.out.println >(System.currentTimeMillis() + name + " thread >created"); > ?} > ?public void run () { > ?try { > ?System.out.println >(System.currentTimeMillis() + name + " opening"); > ?cp = cpi.open(name, 2000); > ?System.out.println >(System.currentTimeMillis() + name + " opened - >sleeping"); > ?sleep (2000); // do the serial comms with the device. > ?System.out.println >(System.currentTimeMillis() + name + " slept - >closing"); > ?cp.close(); > ?System.out.println >(System.currentTimeMillis() + name + " closed - >exiting"); > ?} catch (Exception e) { > System.out.println ("Error in thread: " + name ); > ?e.printStackTrace(); > ?} > ?} >} > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Mar 9 06:37:45 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 Mar 2007 06:37:45 -0700 (MST) Subject: [Rxtx] rxtx: tru64 unix make fails In-Reply-To: References: Message-ID: On Fri, 9 Mar 2007, "Giuseppe Marchese" wrote: > Sorry for delay. > ? > This is log for ./configure and make > error. > ? > thanks for attention > ? > Make: '%.java,$(TOP)/$(CLASSDEST)/%.class,$(wildcard $(SPATH)/*.java)': extra chars.? > Stop. > Hi Giuseppe You need to use GNU make with the Makefile. I suspect the tru64 make is not happy with those rules. > configure: exit 0 Looks like configure is fairly happy. From tjarvi at qbang.org Sat Mar 10 07:43:51 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 07:43:51 -0700 (MST) Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi Doug I have very little time to look into this further but what we could do is open up an rxtx 3 devel branch in which a proof of concept could be worked on. It could be the proof of concept for a JSR others including Sun could look at/work on or parts of it could be recycled in a JSR. I'm working very hard on rxtx right now but it does not show. I'm looking at win64, mac intel/ppc, usb bluetooth and usb serial dongles. Some are going to be more tested than others but they are all on the plate. I'll be pushing all the fixes upstream when they are done. So I'm very busy in 2.1 but we could open a new branch. On Fri, 9 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > The deadlock issue is one that I have been thinking about > for some time now. > It seems to me that we need a resource manager that enables assignment > to a known process. > > The one thing that seems important about serial > ports is that two applications should not use the > same serial port at the same time. When this > happens, it throws an exception. > OK. > > The exception is a response to a lock condition that > arises from an unavailable resource. > > An abstract implementation (not born of native methods) might > assign a serial port to an application, until the > application releases it (or is forced to release > it by some kill mechanism). > > Some resources (like a registry) can be reused. > But others, like the serial port, > cannot. > > In the case of the serial port, we would like, I think, to > have the flyweight design pattern > without sharing and with object assignment tracking. > A means of breaking deadlock (like a leasing > mechanism) seems very useful, to me. > > My guess is that we can serialize the state of the Parametric Singleton Pattern > (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) > into the Preferences of the System. Preferences.systemRoot() might help > with that. When a resource is checked out, the lease time and owner are > listed. A thread that does this can be killed, but applications outside of Java > are problematic. > > There is a compelling problem here. It is not just serial ports. > Sound cards, cameras, microphones, files, tape drives, etc. All are consumed > resources that are assigned to an application (or > user) and deprive other applications, > or users, from use. > > What, if anything, should we do? At present we throw PortInUseExceptions. > Is that it? > Can we do better? > OK, the port is in use. Now what? > Do I have to be root to go remove lock files and kill applications? > Is there a better way? > > Thanks! > - Doug > >> I've just struck an issue using rxtx in a multi-threaded environment: >> >> If I have 3 threads trying to open *the same* >> comm-port I get a deadlock in >> CommPortIdentifier.open >> If I have just 2, it works fine - I get a >> PortInUseException which is nice and I can >> handle it. >> >> The 3 thread->deadlock thing is causing me issues. >> (Sample code below). >> >> This is from the java thread-dump >> >> Found one Java-level deadlock: >> ============================= >> "Thread-2": >> waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), >> which is held by "Thread-1" >> "Thread-1": >> waiting to lock monitor 0x0003e9cc (object >> 0x2450e108, a gnu.io.CommPortIdentifier ), >> which is held by "Thread-2" >> >> Java stack information for the threads listed above: >> =================================================== >> "Thread-2": >> at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) >> - waiting to lock <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> "Thread-1": >> at java.lang.Object.wait(Native Method) >> - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) >> - locked <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> >> >> (Apart from this, rxtx is working fantastically for us). >> >> I'm thinking I'll have to implement some sort of >> locking mechanism that *doesn't* use java >> synchronization to prevent this situation. >> (Which doesn't sound like a good idea to me). >> >> Any ideas? >> >> Thanks, >> >> Greg Hanna >> >> ============= RXTXLockTest.java ======================================== >> >> import gnu.io.CommPort; >> import gnu.io.CommPortIdentifier; >> >> /** >> * @author Greg Hanna >> * Minimal code to create a deadlock with rxtx in multithreaded open >> */ >> public class RXTXLockTest { >> ? >> ?public static void main(String[] args) { >> ?try { >> ?CommPortIdentifier cpiCom1 = >> CommPortIdentifier.getPortIdentifier ("COM14"); >> ?OpenThread t1 = new OpenThread (" one ", cpiCom1); >> ?OpenThread t2 = new OpenThread (" two ", cpiCom1); >> ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); >> ?t1.start(); >> ?t2.start(); >> ?t3.start(); // comment this out >> and it runs with (expected) PortInUseException >> ?} catch (Exception e) { >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> class OpenThread extends Thread { >> ?String name; >> ?CommPortIdentifier cpi; >> ?CommPort cp; >> ?public OpenThread (String name, CommPortIdentifier cpi) { >> ? this.name = name; >> ?this.cpi = cpi; >> ?System.out.println >> (System.currentTimeMillis() + name + " thread >> created"); >> ?} >> ?public void run () { >> ?try { >> ?System.out.println >> (System.currentTimeMillis() + name + " opening"); >> ?cp = cpi.open(name, 2000); >> ?System.out.println >> (System.currentTimeMillis() + name + " opened - >> sleeping"); >> ?sleep (2000); // do the serial comms with the device. >> ?System.out.println >> (System.currentTimeMillis() + name + " slept - >> closing"); >> ?cp.close(); >> ?System.out.println >> (System.currentTimeMillis() + name + " closed - >> exiting"); >> ?} catch (Exception e) { >> System.out.println ("Error in thread: " + name ); >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 mm at UDel.Edu Sat Mar 10 14:48:32 2007 From: mm at UDel.Edu (Mike Markowski) Date: Sat, 10 Mar 2007 16:48:32 -0500 Subject: [Rxtx] rxtx and Sun's comm api Message-ID: <45F327B0.2060004@udel.edu> Hi all, I joined the list a few days ago and apologize for what is likely a frequently asked question, though I haven't yet found it anywhere. I learned about rxtx.org through the readme on Sun's version 2 of their comms api. They give recommendations in that readme regarding how a better comms api should be written. Is this the aim of rxtx.org? I wrote an app on my linux box using the Sun comms api (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the fact that only linux and Solaris are supported. So I'm glad to find rxtx.org and am just reading up on how make the conversion so Windows users will be able to run the program as well. At the same time I'm just curious if rxtx.org and Sun are both heading in the same direction. Thanks for any background or historical info. Feel free to point me to any www pages if my googling has just completely missed the target! Thanks again, Mike From tjarvi at qbang.org Sat Mar 10 15:35:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 15:35:25 -0700 (MST) Subject: [Rxtx] rxtx and Sun's comm api In-Reply-To: <45F327B0.2060004@udel.edu> References: <45F327B0.2060004@udel.edu> Message-ID: On Sat, 10 Mar 2007, Mike Markowski wrote: > Hi all, > > I joined the list a few days ago and apologize for what is likely a > frequently asked question, though I haven't yet found it anywhere. I > learned about rxtx.org through the readme on Sun's version 2 of their > comms api. They give recommendations in that readme regarding how a > better comms api should be written. Is this the aim of rxtx.org? > > I wrote an app on my linux box using the Sun comms api > (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the > fact that only linux and Solaris are supported. So I'm glad to find > rxtx.org and am just reading up on how make the conversion so Windows > users will be able to run the program as well. At the same time I'm > just curious if rxtx.org and Sun are both heading in the same direction. > > Thanks for any background or historical info. Feel free to point me to > any www pages if my googling has just completely missed the target! > I do not have any news (good or bad) concerning RXTX and Sun working together but perhaps others here do. The main goal of RXTX is to expose POSIX termios interfaces to java users. The future support of javax.comm is questionable. We do not have resources for everything. gnu.io (RXTX 2.1) will be supported going forward and functions the same as CommAPI 2.0. If you have control of the source code you are working with, I would not advise using CommAPI 2.0 javax.comm. We do support CommAPI 2.0 javax.comm for older applications but I do not think that will last much longer for practical reasons. The download interest in CommAPI 2.0 javax.comm support is becomming negligible on this end. There has been discussion of a JSR effort but I do not know of any status change since it was mentioned. One problem with a JSR is that even a light weight process is going to be difficult for RXTX at this time. Maybe that will change in the future but then again it may not. For now, we are just going forward 'as is' in rxtx 2.1 with package gnu.io while trying as a secondary effort to backport the changes to rxtx 2.0 for javax.comm support for users that do not have a choice. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Mar 11 07:19:40 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 11 Mar 2007 08:19:40 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: Hi All, I have been a proponent of a JSR that makes use of RXTX. I have executed the proper agreements with Sun. At this point we are in the: Early Draft Review of Draft Specifications Stage. The best thing to do is to enter the quiet period and create a specification. The question of exactly how we, as a group, want to approach this problem, remains open. Typically, we should have both a specification and a reference implementation. Thus, it would be to our best advantage to have a nice, stable, cross platform RXTX distro that adheres to the groups specification. Now, from a specification standpoint, my personal view on the matter is that we create a series of interfaces, with nice documentation (or at least javadoc). Is this a good idea? Should we have a pure interface specification for the communication API? There are several issues, in my mind, which still weigh on us. Hot-pluggable dongles, long discovery process on pop-up ports, lack of uniformity on device names, lack of uniformity on locking, a precise understanding of how the SerialPortResourceManager works (or even if we should have one). The more questions we answer in our reference implementation, the better our specification will get. RXTX is a good working prototype, but, I don't know if that is what we want to use for a specification. Here is what I have for a CommPortInterface: */ public interface CommPortInterface { /** * @return a string representation of this port. */ String toString(); /** * Gets the name of the communications port. This name should correspond to * something the user can identify, like the label on the hardware. * @return name of the port */ String getName(); /** * @return an input stream that can be used to read data from the * communications port. If the port doesn't support reading data, this * method returns null. *

* The blocking behaviour of this input stream depends on the threshold * and timeout values, as shown below for a read buffer size of n * bytes: * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ThresholdTimeoutBlocking behaviour
StateValueStateValue
disableddisabledblock until data is available
enabledm bytesdisabledblock until min(m, n) bytes are available
disabledenabledt msblock for t ms or until data is available
enabledm bytesenabledt msblock for t ms or until min(m, n) bytes are * available
* @throws java.io.IOException */ InputStream getInputStream() throws IOException; /** * @return an output stream that can be used to send data to the * communications port. If the port doesn't support sending data, this * method returns null. * @throws java.io.IOException */ OutputStream getOutputStream() throws IOException; /** * Closes this communications port. * All PortOwnershipListeners will be? * notified of this change of ownership. Further method calls on this? * object will throw IllegalStateException. Further calls on the? * associated InputStream or OutputStream will throw IOException. *

* Close does not block. Undelivered data is discarded. Blocked read and? * write operations are aborted if the underlying operating systems? * supports an IO abort mechanism. To await the delivery of undelivered? * data call OutputStream.flush() or OutputStream.close() before calling? * Port.close(). */ void close(); /** * Enables receive threshold. * When the specified threshold number of bytes are retrieved, read will * return immediately. * * @param thresh the number of bytes in the input buffer * @throws gnu.io.UnsupportedCommOperationException * if receive threshold is * not supported by the driver * @see #disableReceiveThreshold */ void enableReceiveThreshold(int thresh) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive threshold. * * @see #enableReceiveThreshold */ void disableReceiveThreshold(); /** * @return true if receive threshold is enabled. * * @see #enableReceiveThreshold */ boolean isReceiveThresholdEnabled(); /** * @return the receive threshold value. If receive threshold is diabled * or not supported, this value is meaningless. * * @see #enableReceiveThreshold */ int getReceiveThreshold(); /** * Enables receive timeout. * When the specified number of milliseconds have elapsed, read will * return immediately. * * @param rcvTimeout the number of milliseconds to block for * @throws gnu.io.UnsupportedCommOperationException * if receive timeout is * not supported by the driver * @see #disableReceiveTimeout */ void enableReceiveTimeout(int rcvTimeout) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive timeout. * * @see #enableReceiveTimeout */ void disableReceiveTimeout(); /** * @return true if receive timeout is enabled. * * @see #enableReceiveTimeout */ boolean isReceiveTimeoutEnabled(); /** * @return the receive timeout value. If receive timeout is diabled * or not supported, this value is meaningless. * * @see #enableReceiveTimeout */ int getReceiveTimeout(); /** * Enables receive framing. * The supplied byte value in the input suggests the end of the received * frame, and read returns immediately. Only the low 8 bits of the * supplied value are significant. * * @param framingByte the frame delimiter * @throws gnu.io.UnsupportedCommOperationException * if receive framing is * not supported by the driver * @see #disableReceiveFraming */ void enableReceiveFraming(int framingByte) throws UnsupportedCommOperationException; /** * Disables receive framing. * * @see #enableReceiveFraming */ void disableReceiveFraming(); /** * @return true if receive framing is enabled. * * @see #enableReceiveFraming */ boolean isReceiveFramingEnabled(); /** * @return true if receive framing byte. If receive framing is diabled * or not supported, this value is meaningless. * * @see #enableReceiveFraming */ int getReceiveFramingByte(); /** * Sets the input buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setInputBufferSize(int size); /** * @return the input buffer size. * The driver may choose not to report correct values. */ int getInputBufferSize(); /** * Sets the output buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setOutputBufferSize(int size); /** * @return the output buffer size. * The driver may choose not to report correct values. */ int getOutputBufferSize(); } What do you think of that? Note the wishy washy nature of the spec: The driver may choose to ignore this method. Is that good enough for us? Thanks! - Doug From ra85551 at gmail.com Sun Mar 11 08:44:45 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Sun, 11 Mar 2007 17:44:45 +0300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hello, world! I am writing application that communicates with modem via AT commands. My OS is Linux Kubuntu Feisty Herd, to ensure that my application will run properly under Windows XP I installed VMWare server. When I tried to send AT command and evaluate modem answer under WinXP @ VMWare server, I actually didn't receive anything. I think that VM settings are right, because I do can communicate with modem by using standard HyperTerminall as well as I can do on native Windows. So, why RXTX doesn't work under VM, but works under Linux and pure Windows XP (i tested it there) well? The send/receive method code follows. private String sendATCommand(String command, final String waitFor, final boolean isRegex, boolean isAddCRLF, long timeout) throws BeaconConnectException { final long POLL_PERIOD = 100; final int BUFFER_SIZE = 512; final byte[] buffer = new byte[BUFFER_SIZE]; final InputStream serialInput; final OutputStream serialOutput; try { serialInput = serialPort.getInputStream(); if (command != null) { serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } } catch (IOException e) { throw new MyException("serial I/O error"); } TimerTask task = new TimerTask() { int offset = 0; int bytesRead; public synchronized void run() { try { if (serialInput.available() > 0) { bytesRead = serialInput.read(buffer, offset, BUFFER_SIZE - offset); } else { return; } } catch (IOException e) { // do nothing - maybe next time we'll read something } offset += bytesRead; if (waitFor != null) { String temporary = new String(buffer, 0, offset).trim(); if (isRegex && temporary.matches(waitFor) || temporary.contains(waitFor)) { cancel(); notify(); } } } }; Timer timer = new Timer(); timer.schedule(task, POLL_PERIOD, POLL_PERIOD); synchronized (task) { try { task.wait(timeout); task.cancel(); } catch (InterruptedException e) { } } //Cut off leading and trailing CRs, LFs and zeroes String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); System.out.println(response); return response; } -- Pavel Parkhomenko From tjarvi at qbang.org Sun Mar 11 11:48:22 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:48:22 -0600 (MDT) Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: On Sun, 11 Mar 2007, Pavel Parkhomenko wrote: > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. > > private String sendATCommand(String command, final String waitFor, > final boolean isRegex, boolean isAddCRLF, long timeout) > throws BeaconConnectException > { > final long POLL_PERIOD = 100; > final int BUFFER_SIZE = 512; > final byte[] buffer = new byte[BUFFER_SIZE]; > final InputStream serialInput; > final OutputStream serialOutput; > try > { > serialInput = serialPort.getInputStream(); > if (command != null) > { > serialOutput = serialPort.getOutputStream(); > if (isAddCRLF) > { > command += "\r\n"; > } > System.out.println(command); > serialOutput.write(command.getBytes()); > } > } > catch (IOException e) > { > throw new MyException("serial I/O error"); > } > > TimerTask task = new TimerTask() > { > int offset = 0; > int bytesRead; > public synchronized void run() > { > try > { > if (serialInput.available() > 0) > { > bytesRead = serialInput.read(buffer, offset, > BUFFER_SIZE - offset); > } > else > { > return; > } > } > catch (IOException e) > { > // do nothing - maybe next time we'll read something > } > offset += bytesRead; > if (waitFor != null) > { > String temporary = new String(buffer, 0, offset).trim(); > if (isRegex && temporary.matches(waitFor) || > temporary.contains(waitFor)) > { > cancel(); > notify(); > } > } > } > }; > > Timer timer = new Timer(); > timer.schedule(task, POLL_PERIOD, POLL_PERIOD); > synchronized (task) { > try > { > task.wait(timeout); > task.cancel(); > } > catch (InterruptedException e) > { > } > } > //Cut off leading and trailing CRs, LFs and zeroes > String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); > System.out.println(response); > return response; > } > > > Hi Pavel VMWare should not be a problem. I've used it in the past - though not with a modem. Make sure nothing else is using the modem. Then look in the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an example that should work. Note that modems could care less what OS is on top. If you are trying to match new lines to the OS and sending it to the mode for AT commands, thats probably a mistake. Also it would not hurt to print out the individual bytes that you are sending to make sure they did not get mangled along the path. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 11:55:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:55:48 -0600 (MDT) Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: On Sun, 11 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > I have been a proponent of a JSR that makes > use of RXTX. I have executed the proper agreements with Sun. > > At this point we are in the: > Early Draft Review of Draft Specifications Stage. > > The best thing to do is to enter the quiet period and create > a specification. The question of exactly how we, as a group, > want to approach this problem, remains open. > > Typically, we should have both a specification and a reference > implementation. Thus, it would be to our best advantage to have > a nice, stable, cross platform RXTX distro that adheres to the > groups specification. > > Now, from a specification standpoint, my personal view on the matter is > that we create a series of interfaces, with nice documentation (or at least > javadoc). > > Is this a good idea? Should we have a pure interface specification for > the communication API? > > There are several issues, in my mind, which still weigh on us. > Hot-pluggable dongles, long discovery process on pop-up ports, > lack of uniformity on device names, lack of uniformity on locking, > a precise understanding of how the SerialPortResourceManager > works (or even if we should have one). > > The more questions we answer in our reference implementation, the > better our specification will get. RXTX is a good working prototype, > but, I don't know if that is what we want to use for a specification. > > Here is what I have for a CommPortInterface: > */ > public interface CommPortInterface { Hi Doug, I can start going through the method interfaces later this week and giving feedback. I would suggest that the JSR should not be too generic in nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel drivers that intend to look like EIA232 ports at the kernel driver level. some ideas: EIA232PortInterface TermiosInterface SerialPortInterface Something that differentiates this from thing like USB, I2C, ... which should not have to deal with legacy serial claiming to be the comm api. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 12:52:19 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 12:52:19 -0600 (MDT) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: No news is good news with these posts. I'll start the process of pinging legal a week from Monday on my end if nobody has objections to the proposal. I just want to make sure everyone has time to raise objections. Obviously, anyone can fork from a previous version if they don't like the new license. I suspect we can avoid that though. On Sun, 4 Mar 2007, Trent Jarvi wrote: > > For those that are wondering what is going on here, this > next bit is the meat of the changes. We agreed a long time > ago to put this disclaimer in. We did a so so job. It was > in rxtx 2.0, not well written, ... So some groups using > rxtx that would like to ship rxtx so users don't need to > download, install, go to the mail-list to find why it failed, > ... Then their legal teams tell them section 5 paragraph 2 > is a show stopper. > > That was never the intent. > > > Now going through what remains... > >> and might need a (TM) suffix to make Sun happy. > > Added disclaimer at the ended 'all trademarks belong...' > >> * Line #15ff - static vs. dynamic linking - you did >> not transcribe the text from the "controlled >> interface exception" when writing this text - and >> this was good so, because these terms originally >> refer to the GPL rather than the LGPL. I think though, >> that these 4 lines are the most important ones and >> should thus be really really clear. I hope that I >> meet your original intent with the following >> suggestions: >> 1.) Instead of "A program.." it would be better to >> say "An exectuable.." in order to be closer to >> the LGPL text. > > OK. As you can see I was trying to adjust GNU text there > for the LGPL. > >> 2.) It would be better to say .. "by being dynamically >> linked with it" to clearly indicate that dynamic >> linking is meant. The matter of compilation is >> already covered by the LGPL so mentioning it again >> just leads to confusion. > > used dynamically linked terminology. > >> 3.) It would be better to say .. "is considered a >> work that uses the library in contrast to section >> 5 of the LGPL, so the terms of the LGPL do not >> apply to the resulting executable". > > I tried to address this more upfront with an intent statement. > Let me know if you have problems with it. I also tried to > make it a little more clear what was derived from the GNU > solution by moving the link location closer to GNU's suggestion. > >> >> Note that LGPL section 5 says: ..."is called a >> "work that uses the Library". Such a work, in isolation, >> is not a derivative work of the Library, and therefore >> falls outside the scope of this License." >> The next paragraph of the LGPL is exactly the problematic >> one that I hope is clarified by the exception terms you >> give. >> > > Thats the intent. Here is the combined fixes. Note that only the > material in /*-- --*/ is being touched. The new GPL license is > there but unmodified. > > > ------------------------ begin proposed new license ------------------- > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Lesser General Public > | License as published by the Free Software Foundation; either > | version 2.1 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Lesser General Public License for more details. > | > | An executable that contains no derivative of any portion of RXTX, but > | is designed to work with RXTX by being dynamically linked with it, > | is considered a "work that uses the Library" subject to the terms and > | conditions of the GNU Lesser General Public License. > | > | The following has been added to the RXTX License to remove > | any confusion about linking to RXTX. We want to allow in part what > | section 5, paragraph 2 of the LGPL does not permit in the special > | case of linking over a controlled interface. The intent is to add a > | Java Specification Request or standards body defined interface in the > | future as another exception but one is not currently available. > | > | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface > | > | As a special exception, the copyright holders of RXTX give you > | permission to link RXTX with independent modules that communicate with > | RXTX solely through the Sun Microsytems CommAPI interface version 2, > | regardless of the license terms of these independent modules, and to copy > | and distribute the resulting combined work under terms of your choice, > | provided that every copy of the combined work is accompanied by a complete > | copy of the source code of RXTX (the version of RXTX used to produce the > | combined work), being distributed under the terms of the GNU Lesser General > | Public License plus this exception. An independent module is a > | module which is not derived from or based on RXTX. > | > | Note that people who make modified versions of RXTX are not obligated > | to grant this special exception for their modified versions; it is > | their choice whether to do so. The GNU Lesser General Public License > | gives permission to release a modified version without this exception; this > | exception also makes it possible to release a modified version which > | carries forward this exception. > | > | You should have received a copy of the GNU Lesser General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > | All trademarks belong to their respective owners. > --------------------------------------------------------------------------*/ > > The original GNU Lesser General Public License Follows. > > > GNU LESSER GENERAL PUBLIC LICENSE > Version 2.1, February 1999 > > Copyright (C) 1991, 1999 Free Software Foundation, Inc. > 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > Everyone is permitted to copy and distribute verbatim copies > of this license document, but changing it is not allowed. > > [This is the first released version of the Lesser GPL. It also counts > as the successor of the GNU Library Public License, version 2, hence > the version number 2.1.] > > Preamble > > The licenses for most software are designed to take away your > freedom to share and change it. By contrast, the GNU General Public > Licenses are intended to guarantee your freedom to share and change > free software--to make sure the software is free for all its users. > > This license, the Lesser General Public License, applies to some > specially designated software packages--typically libraries--of the > Free Software Foundation and other authors who decide to use it. You > can use it too, but we suggest you first think carefully about whether > this license or the ordinary General Public License is the better > strategy to use in any particular case, based on the explanations below. > > When we speak of free software, we are referring to freedom of use, > not price. Our General Public Licenses are designed to make sure that > you have the freedom to distribute copies of free software (and charge > for this service if you wish); that you receive source code or can get > it if you want it; that you can change the software and use pieces of > it in new free programs; and that you are informed that you can do > these things. > > To protect your rights, we need to make restrictions that forbid > distributors to deny you these rights or to ask you to surrender these > rights. These restrictions translate to certain responsibilities for > you if you distribute copies of the library or if you modify it. > > For example, if you distribute copies of the library, whether gratis > or for a fee, you must give the recipients all the rights that we gave > you. You must make sure that they, too, receive or can get the source > code. If you link other code with the library, you must provide > complete object files to the recipients, so that they can relink them > with the library after making changes to the library and recompiling > it. And you must show them these terms so they know their rights. > > We protect your rights with a two-step method: (1) we copyright the > library, and (2) we offer you this license, which gives you legal > permission to copy, distribute and/or modify the library. > > To protect each distributor, we want to make it very clear that > there is no warranty for the free library. Also, if the library is > modified by someone else and passed on, the recipients should know > that what they have is not the original version, so that the original > author's reputation will not be affected by problems that might be > introduced by others. > > Finally, software patents pose a constant threat to the existence of > any free program. We wish to make sure that a company cannot > effectively restrict the users of a free program by obtaining a > restrictive license from a patent holder. Therefore, we insist that > any patent license obtained for a version of the library must be > consistent with the full freedom of use specified in this license. > > Most GNU software, including some libraries, is covered by the > ordinary GNU General Public License. This license, the GNU Lesser > General Public License, applies to certain designated libraries, and > is quite different from the ordinary General Public License. We use > this license for certain libraries in order to permit linking those > libraries into non-free programs. > > When a program is linked with a library, whether statically or using > a shared library, the combination of the two is legally speaking a > combined work, a derivative of the original library. The ordinary > General Public License therefore permits such linking only if the > entire combination fits its criteria of freedom. The Lesser General > Public License permits more lax criteria for linking other code with > the library. > > We call this license the "Lesser" General Public License because it > does Less to protect the user's freedom than the ordinary General > Public License. It also provides other free software developers Less > of an advantage over competing non-free programs. These disadvantages > are the reason we use the ordinary General Public License for many > libraries. However, the Lesser license provides advantages in certain > special circumstances. > > For example, on rare occasions, there may be a special need to > encourage the widest possible use of a certain library, so that it becomes > a de-facto standard. To achieve this, non-free programs must be > allowed to use the library. A more frequent case is that a free > library does the same job as widely used non-free libraries. In this > case, there is little to gain by limiting the free library to free > software only, so we use the Lesser General Public License. > > In other cases, permission to use a particular library in non-free > programs enables a greater number of people to use a large body of > free software. For example, permission to use the GNU C Library in > non-free programs enables many more people to use the whole GNU > operating system, as well as its variant, the GNU/Linux operating > system. > > Although the Lesser General Public License is Less protective of the > users' freedom, it does ensure that the user of a program that is > linked with the Library has the freedom and the wherewithal to run > that program using a modified version of the Library. > > The precise terms and conditions for copying, distribution and > modification follow. Pay close attention to the difference between a > "work based on the library" and a "work that uses the library". The > former contains code derived from the library, whereas the latter must > be combined with the library in order to run. > > GNU LESSER GENERAL PUBLIC LICENSE > TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION > > 0. This License Agreement applies to any software library or other > program which contains a notice placed by the copyright holder or > other authorized party saying it may be distributed under the terms of > this Lesser General Public License (also called "this License"). > Each licensee is addressed as "you". > > A "library" means a collection of software functions and/or data > prepared so as to be conveniently linked with application programs > (which use some of those functions and data) to form executables. > > The "Library", below, refers to any such software library or work > which has been distributed under these terms. A "work based on the > Library" means either the Library or any derivative work under > copyright law: that is to say, a work containing the Library or a > portion of it, either verbatim or with modifications and/or translated > straightforwardly into another language. (Hereinafter, translation is > included without limitation in the term "modification".) > > "Source code" for a work means the preferred form of the work for > making modifications to it. For a library, complete source code means > all the source code for all modules it contains, plus any associated > interface definition files, plus the scripts used to control compilation > and installation of the library. > > Activities other than copying, distribution and modification are not > covered by this License; they are outside its scope. The act of > running a program using the Library is not restricted, and output from > such a program is covered only if its contents constitute a work based > on the Library (independent of the use of the Library in a tool for > writing it). Whether that is true depends on what the Library does > and what the program that uses the Library does. > > 1. You may copy and distribute verbatim copies of the Library's > complete source code as you receive it, in any medium, provided that > you conspicuously and appropriately publish on each copy an > appropriate copyright notice and disclaimer of warranty; keep intact > all the notices that refer to this License and to the absence of any > warranty; and distribute a copy of this License along with the > Library. > > You may charge a fee for the physical act of transferring a copy, > and you may at your option offer warranty protection in exchange for a > fee. > > 2. You may modify your copy or copies of the Library or any portion > of it, thus forming a work based on the Library, and copy and > distribute such modifications or work under the terms of Section 1 > above, provided that you also meet all of these conditions: > > a) The modified work must itself be a software library. > > b) You must cause the files modified to carry prominent notices > stating that you changed the files and the date of any change. > > c) You must cause the whole of the work to be licensed at no > charge to all third parties under the terms of this License. > > d) If a facility in the modified Library refers to a function or a > table of data to be supplied by an application program that uses > the facility, other than as an argument passed when the facility > is invoked, then you must make a good faith effort to ensure that, > in the event an application does not supply such function or > table, the facility still operates, and performs whatever part of > its purpose remains meaningful. > > (For example, a function in a library to compute square roots has > a purpose that is entirely well-defined independent of the > application. Therefore, Subsection 2d requires that any > application-supplied function or table used by this function must > be optional: if the application does not supply it, the square > root function must still compute square roots.) > > These requirements apply to the modified work as a whole. If > identifiable sections of that work are not derived from the Library, > and can be reasonably considered independent and separate works in > themselves, then this License, and its terms, do not apply to those > sections when you distribute them as separate works. But when you > distribute the same sections as part of a whole which is a work based > on the Library, the distribution of the whole must be on the terms of > this License, whose permissions for other licensees extend to the > entire whole, and thus to each and every part regardless of who wrote > it. > > Thus, it is not the intent of this section to claim rights or contest > your rights to work written entirely by you; rather, the intent is to > exercise the right to control the distribution of derivative or > collective works based on the Library. > > In addition, mere aggregation of another work not based on the Library > with the Library (or with a work based on the Library) on a volume of > a storage or distribution medium does not bring the other work under > the scope of this License. > > 3. You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. To do > this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version 2, > instead of to this License. (If a newer version than version 2 of the > ordinary GNU General Public License has appeared, then you can specify > that version instead if you wish.) Do not make any other change in > these notices. > > Once this change is made in a given copy, it is irreversible for > that copy, so the ordinary GNU General Public License applies to all > subsequent copies and derivative works made from that copy. > > This option is useful when you wish to copy part of the code of > the Library into a program that is not a library. > > 4. You may copy and distribute the Library (or a portion or > derivative of it, under Section 2) in object code or executable form > under the terms of Sections 1 and 2 above provided that you accompany > it with the complete corresponding machine-readable source code, which > must be distributed under the terms of Sections 1 and 2 above on a > medium customarily used for software interchange. > > If distribution of object code is made by offering access to copy > from a designated place, then offering equivalent access to copy the > source code from the same place satisfies the requirement to > distribute the source code, even though third parties are not > compelled to copy the source along with the object code. > > 5. A program that contains no derivative of any portion of the > Library, but is designed to work with the Library by being compiled or > linked with it, is called a "work that uses the Library". Such a > work, in isolation, is not a derivative work of the Library, and > therefore falls outside the scope of this License. > > However, linking a "work that uses the Library" with the Library > creates an executable that is a derivative of the Library (because it > contains portions of the Library), rather than a "work that uses the > library". The executable is therefore covered by this License. > Section 6 states terms for distribution of such executables. > > When a "work that uses the Library" uses material from a header file > that is part of the Library, the object code for the work may be a > derivative work of the Library even though the source code is not. > Whether this is true is especially significant if the work can be > linked without the Library, or if the work is itself a library. The > threshold for this to be true is not precisely defined by law. > > If such an object file uses only numerical parameters, data > structure layouts and accessors, and small macros and small inline > functions (ten lines or less in length), then the use of the object > file is unrestricted, regardless of whether it is legally a derivative > work. (Executables containing this object code plus portions of the > Library will still fall under Section 6.) > > Otherwise, if the work is a derivative of the Library, you may > distribute the object code for the work under the terms of Section 6. > Any executables containing that work also fall under Section 6, > whether or not they are linked directly with the Library itself. > > 6. As an exception to the Sections above, you may also combine or > link a "work that uses the Library" with the Library to produce a > work containing portions of the Library, and distribute that work > under terms of your choice, provided that the terms permit > modification of the work for the customer's own use and reverse > engineering for debugging such modifications. > > You must give prominent notice with each copy of the work that the > Library is used in it and that the Library and its use are covered by > this License. You must supply a copy of this License. If the work > during execution displays copyright notices, you must include the > copyright notice for the Library among them, as well as a reference > directing the user to the copy of this License. Also, you must do one > of these things: > > a) Accompany the work with the complete corresponding > machine-readable source code for the Library including whatever > changes were used in the work (which must be distributed under > Sections 1 and 2 above); and, if the work is an executable linked > with the Library, with the complete machine-readable "work that > uses the Library", as object code and/or source code, so that the > user can modify the Library and then relink to produce a modified > executable containing the modified Library. (It is understood > that the user who changes the contents of definitions files in the > Library will not necessarily be able to recompile the application > to use the modified definitions.) > > b) Use a suitable shared library mechanism for linking with the > Library. A suitable mechanism is one that (1) uses at run time a > copy of the library already present on the user's computer system, > rather than copying library functions into the executable, and (2) > will operate properly with a modified version of the library, if > the user installs one, as long as the modified version is > interface-compatible with the version that the work was made with. > > c) Accompany the work with a written offer, valid for at > least three years, to give the same user the materials > specified in Subsection 6a, above, for a charge no more > than the cost of performing this distribution. > > d) If distribution of the work is made by offering access to copy > from a designated place, offer equivalent access to copy the above > specified materials from the same place. > > e) Verify that the user has already received a copy of these > materials or that you have already sent this user a copy. > > For an executable, the required form of the "work that uses the > Library" must include any data and utility programs needed for > reproducing the executable from it. However, as a special exception, > the materials to be distributed need not include anything that is > normally distributed (in either source or binary form) with the major > components (compiler, kernel, and so on) of the operating system on > which the executable runs, unless that component itself accompanies > the executable. > > It may happen that this requirement contradicts the license > restrictions of other proprietary libraries that do not normally > accompany the operating system. Such a contradiction means you cannot > use both them and the Library together in an executable that you > distribute. > > 7. You may place library facilities that are a work based on the > Library side-by-side in a single library together with other library > facilities not covered by this License, and distribute such a combined > library, provided that the separate distribution of the work based on > the Library and of the other library facilities is otherwise > permitted, and provided that you do these two things: > > a) Accompany the combined library with a copy of the same work > based on the Library, uncombined with any other library > facilities. This must be distributed under the terms of the > Sections above. > > b) Give prominent notice with the combined library of the fact > that part of it is a work based on the Library, and explaining > where to find the accompanying uncombined form of the same work. > > 8. You may not copy, modify, sublicense, link with, or distribute > the Library except as expressly provided under this License. Any > attempt otherwise to copy, modify, sublicense, link with, or > distribute the Library is void, and will automatically terminate your > rights under this License. However, parties who have received copies, > or rights, from you under this License will not have their licenses > terminated so long as such parties remain in full compliance. > > 9. You are not required to accept this License, since you have not > signed it. However, nothing else grants you permission to modify or > distribute the Library or its derivative works. These actions are > prohibited by law if you do not accept this License. Therefore, by > modifying or distributing the Library (or any work based on the > Library), you indicate your acceptance of this License to do so, and > all its terms and conditions for copying, distributing or modifying > the Library or works based on it. > > 10. Each time you redistribute the Library (or any work based on the > Library), the recipient automatically receives a license from the > original licensor to copy, distribute, link with or modify the Library > subject to these terms and conditions. You may not impose any further > restrictions on the recipients' exercise of the rights granted herein. > You are not responsible for enforcing compliance by third parties with > this License. > > 11. If, as a consequence of a court judgment or allegation of patent > infringement or for any other reason (not limited to patent issues), > conditions are imposed on you (whether by court order, agreement or > otherwise) that contradict the conditions of this License, they do not > excuse you from the conditions of this License. If you cannot > distribute so as to satisfy simultaneously your obligations under this > License and any other pertinent obligations, then as a consequence you > may not distribute the Library at all. For example, if a patent > license would not permit royalty-free redistribution of the Library by > all those who receive copies directly or indirectly through you, then > the only way you could satisfy both it and this License would be to > refrain entirely from distribution of the Library. > > If any portion of this section is held invalid or unenforceable under any > particular circumstance, the balance of the section is intended to apply, > and the section as a whole is intended to apply in other circumstances. > > It is not the purpose of this section to induce you to infringe any > patents or other property right claims or to contest validity of any > such claims; this section has the sole purpose of protecting the > integrity of the free software distribution system which is > implemented by public license practices. Many people have made > generous contributions to the wide range of software distributed > through that system in reliance on consistent application of that > system; it is up to the author/donor to decide if he or she is willing > to distribute software through any other system and a licensee cannot > impose that choice. > > This section is intended to make thoroughly clear what is believed to > be a consequence of the rest of this License. > > 12. If the distribution and/or use of the Library is restricted in > certain countries either by patents or by copyrighted interfaces, the > original copyright holder who places the Library under this License may add > an explicit geographical distribution limitation excluding those countries, > so that distribution is permitted only in or among countries not thus > excluded. In such case, this License incorporates the limitation as if > written in the body of this License. > > 13. The Free Software Foundation may publish revised and/or new > versions of the Lesser General Public License from time to time. > Such new versions will be similar in spirit to the present version, > but may differ in detail to address new problems or concerns. > > Each version is given a distinguishing version number. If the Library > specifies a version number of this License which applies to it and > "any later version", you have the option of following the terms and > conditions either of that version or of any later version published by > the Free Software Foundation. If the Library does not specify a > license version number, you may choose any version ever published by > the Free Software Foundation. > > 14. If you wish to incorporate parts of the Library into other free > programs whose distribution conditions are incompatible with these, > write to the author to ask for permission. For software which is > copyrighted by the Free Software Foundation, write to the Free > Software Foundation; we sometimes make exceptions for this. Our > decision will be guided by the two goals of preserving the free status > of all derivatives of our free software and of promoting the sharing > and reuse of software generally. > > NO WARRANTY > > 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO > WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. > EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR > OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY > KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE > IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE > LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME > THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. > > 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN > WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY > AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU > FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR > CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE > LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING > RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A > FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF > SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH > DAMAGES. > > END OF TERMS AND CONDITIONS > > How to Apply These Terms to Your New Libraries > > If you develop a new library, and you want it to be of the greatest > possible use to the public, we recommend making it free software that > everyone can redistribute and change. You can do so by permitting > redistribution under these terms (or, alternatively, under the terms of the > ordinary General Public License). > > To apply these terms, attach the following notices to the library. It is > safest to attach them to the start of each source file to most effectively > convey the exclusion of warranty; and each file should have at least the > "copyright" line and a pointer to where the full notice is found. > > > Copyright (C) > > This library is free software; you can redistribute it and/or > modify it under the terms of the GNU Lesser General Public > License as published by the Free Software Foundation; either > version 2.1 of the License, or (at your option) any later version. > > This library is distributed in the hope that it will be useful, > but WITHOUT ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > Lesser General Public License for more details. > > You should have received a copy of the GNU Lesser General Public > License along with this library; if not, write to the Free Software > Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > > Also add information on how to contact you by electronic and paper mail. > > You should also get your employer (if you work as a programmer) or your > school, if any, to sign a "copyright disclaimer" for the library, if > necessary. Here is a sample; alter the names: > > Yoyodyne, Inc., hereby disclaims all copyright interest in the > library `Frob' (a library for tweaking knobs) written by James Random Hacker. > > , 1 April 1990 > Ty Coon, President of Vice > > That's all there is to it! > ------------------------ end of proposed license ------------------ > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From gjhanna at gmail.com Sun Mar 11 14:21:17 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Mon, 12 Mar 2007 09:21:17 +1300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hi Pavel, We are using RXTX under VMWare server in production, quite satisfactorily. We're using Red Hat Enterprise Server 4, and ... Whatever the "enterprise" VMWare product is. Regards, Greg H > Subject: [Rxtx] RXTX under VMWare server > To: rxtx at qbang.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. [ ... snip ... ] -- Pavel Parkhomenko -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070311/4cebb6f9/attachment-0006.html From gergg at cox.net Sun Mar 11 23:39:19 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 12 Mar 2007 00:39:19 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: <45F4E787.6050502@cox.net> Trent Jarvi wrote: > I can start going through the method interfaces later this week and giving > feedback. I would suggest that the JSR should not be too generic in > nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel > drivers that intend to look like EIA232 ports at the kernel driver level. > > some ideas: > > EIA232PortInterface > TermiosInterface > SerialPortInterface > > Something that differentiates this from thing like USB, I2C, ... which > should not have to deal with legacy serial claiming to be the comm api. I'm going to throw out a suggestion, which I am mostly serious about. What would happen if we took the appropriate bits of the J2ME connector API, and just used that as the new COMM API so that finally JSE and JME had a common foundation for these kinds of things? Gregg Wonderly From ra85551 at gmail.com Mon Mar 12 09:08:37 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Mon, 12 Mar 2007 18:08:37 +0300 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Should any application use the modem, HyperTerminal won't be able to talk to the modem. But it actually can send and receive AT comands, while my application cannot :-( > Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Thansk for the reference. I examined that example and found that there's no significant differences between my read/write implementation and that one, except that SimpleSnuV1 listens for serialEvent's, but not for sake of data retrieval, just for printing them out - I don't know why ;-) > Note that modems could care less what OS is on top. If you are trying to > match new lines to the OS and sending it to the mode for AT commands, > thats probably a mistake. I do send strings to serial port, not to OS, and do try to get answers back. If it is the mistake, what's the right way? > Also it would not hurt to print out the > individual bytes that you are sending to make sure they did not get > mangled along the path. Yeah, I am printing these bytes before doing write, but it means that I only see what I intend to write. How can I ensure that these bytes have gone out of the box and reached my modem? BTW, I found that my send/receive method is complex enough, so I've rewritten it. Please, see the following code and point any mistakes, because I don't know where can they remain yet. private static final int LARGE_TIMEOUT = 15000; private static final int SMALL_TIMEOUT = 500; ... private String sendATCommand(String command, String waitFor, boolean isRegex, boolean isAddCRLF) throws BeaconConnectException { byte[] buffer = new byte[512]; int offset; String result = ""; try { if (waitFor != null) { serialPort.enableReceiveTimeout(LARGE_TIMEOUT); } else { serialPort.enableReceiveTimeout(SMALL_TIMEOUT); } if (command != null) { OutputStream serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } offset = 0; InputStream serialInput = serialPort.getInputStream(); while (serialInput.available() != -1) { int bytesRead = serialInput.read(buffer, offset, buffer.length - offset); if (bytesRead == 0) { break; } offset += bytesRead; result = new String(buffer, 0, offset).trim(); if (waitFor != null) { System.out.println(result); if (isRegex && result.matches(waitFor) || result.contains(waitFor)) { break; } } } } catch (UnsupportedCommOperationException e) { throw new MyException("unsupported operation"); } catch (IOException e) { throw new MytException("serial I/O error"); } return result; } -- Pavel Parkhomenko From clayno at hotpop.com Thu Mar 15 02:47:34 2007 From: clayno at hotpop.com (Christopher Layno) Date: Thu, 15 Mar 2007 16:47:34 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi, we're using the latest release of rxtx (2.1-7r2) for our system that has two applications using the library. one application sends requests to the modem while the other simply checks the modem status. we deployed our system on a pentium machine with red hat linux 9.0 installed. now the problem arises when these two applications try to access the same modem at the same time. one of them will eventually have to throw the PortInUseException as shown below: 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException gnu.io.PortInUseException: root PID = 743 Program = java root PID = 743 Program = java root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) this was expected. what we didn't expect though was that if we repeat the scenario 5 times, always 5 times, the application would also throw a VM error: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4473CD21 Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so Current Java thread: at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) - locked <0x44cfd4c8> (a gnu.io.CommPortIdentifier) at ************ at ************ - locked <0x4476a468> (a **********) at ************ at ************ at ************ at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java :261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages( TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run( TCPTransport.java:701) at java.lang.Thread.run(Thread.java:534) note: i replaced some sensitive data with asterisks our team has looked everywhere on the internet, including your mail archives, for a solution to this problem but to no avail. i really hope you could help us out on this one. thanks in advance! best regards, chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070315/1936460a/attachment-0006.html From tjarvi at qbang.org Fri Mar 16 04:30:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 04:30:25 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: On Thu, 15 Mar 2007, Christopher Layno wrote: > hi, > > we're using the latest release of rxtx (2.1-7r2) for our system that has two > applications using the library. one application sends requests to the modem > while the other simply checks the modem status. we deployed our system on a > pentium machine with red hat linux 9.0 installed. > > now the problem arises when these two applications try to access the same > modem at the same time. one of them will eventually have to throw the > PortInUseException as shown below: > > 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException > gnu.io.PortInUseException: root PID = 743 Program = java root PID = > 743 Program = java root PID = 743 Program = ??? root PID = 743 Program > = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root > PID = 743 Program = ??? root PID = 743 Program = ??? > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > > this was expected. what we didn't expect though was that if we repeat the > scenario 5 times, always 5 times, the application would also throw a VM > error: > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x4473CD21 > Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 > Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so > > Current Java thread: > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) Hi Chris The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. The code is originally by Werner Almesberger. He gave us permission to use it in rxtx. You might look at what has changed since 1998 in his fuser application. Or you can just do like other OSs and do the following in fuserImp.c JNIEXPORT jstring JNICALL Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv *env, jobject obj, jstring arg) { return (*env)->NewStringUTF(env, "Unknown Application"); } It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. -- Trent Jarvi tjarvi at qang.org From Adrien.TOS at ingenico.com Fri Mar 16 05:11:12 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Fri, 16 Mar 2007 12:11:12 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903CBC312@frsnprexc1.usr.ingenico.loc> Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070316/972ab214/attachment-0006.html From joachim at buechse.de Fri Mar 16 05:13:24 2007 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 16 Mar 2007 12:13:24 +0100 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. From tjarvi at qbang.org Fri Mar 16 16:36:29 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 16:36:29 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Fri Mar 16 16:02:23 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 16 Mar 2007 18:02:23 -0400 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Not all platforms are Unix based. Also mixing native library usage and command-line calls is not an elegant solution, IMHO. One or the other, but not both. Andre On 16-Mar-07, at 07:13 , Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is > trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We >> only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From clayno at hotpop.com Sun Mar 18 22:17:28 2007 From: clayno at hotpop.com (Christopher Layno) Date: Mon, 19 Mar 2007 12:17:28 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi everyone, thank you so much for your replies. they were really helpful. anyway, before i sent the email, my team was already implementing a temporary solution by using joachim's suggestion. we invoked a lsof command from our java code although i share the same concern with trent and andre-john about portability issues. that's why i said it's just temporary. my superiors have yet to approve our bug fix. so my question now is this: is recompiling the rxtx source code the only way to solve this problem? because if it's the only solution, then i think my superiors would rather have a new release from the rxtx community itself that fixes this bug(?) rather than have my team recompile the source code. best regards, chris Trent Jarvi wrote: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. ... It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070318/237463b2/attachment-0006.html From tjarvi at qbang.org Mon Mar 19 16:20:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Mar 2007 16:20:52 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: Hi Chris I can compile a new version after the 21st if you do not feel comfortable doing so. Please send me an email reminder off-line then. On Mon, 19 Mar 2007, Christopher Layno wrote: > hi everyone, > > thank you so much for your replies. they were really helpful. > > anyway, before i sent the email, my team was already implementing a > temporary solution by using joachim's suggestion. > we invoked a lsof command from our java code although i share the same > concern with trent and andre-john about > portability issues. that's why i said it's just temporary. my superiors have > yet to approve our bug fix. > > so my question now is this: is recompiling the rxtx source code the only way > to solve this problem? because if it's the only > solution, then i think my superiors would rather have a new release from the > rxtx community itself that fixes this bug(?) > rather than have my team recompile the source code. > > best regards, > > chris > > Trent Jarvi wrote: > > Hi Joachim > > It would be nice to have that functionality but calling the program > introduces too many issues imho. Explaining to someone why rxtx invoked a > rogue lsof does not sound very interesting. > > On Fri, 16 Mar 2007, Joachim Buechse wrote: > > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: > > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. > > _______________________________________________ > Rxtx mailing list > Rxtx 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 Eric.Arseneau at sun.com Tue Mar 20 11:47:33 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Tue, 20 Mar 2007 10:47:33 -0700 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 Message-ID: <46001E35.9040608@sun.com> Anyone have any experience with RXTX working with JDK 6 on other platforms ? From mm at UDel.Edu Tue Mar 20 12:18:29 2007 From: mm at UDel.Edu (Mike Markowski) Date: Tue, 20 Mar 2007 14:18:29 -0400 Subject: [Rxtx] I seem to have issues with Solaris x86 Nevada b59 and JDK6 In-Reply-To: <46001E35.9040608@sun.com> References: <46001E35.9040608@sun.com> Message-ID: <46002575.4000306@udel.edu> Eric Arseneau wrote: > Anyone have any experience with RXTX working with JDK 6 on other platforms ? I'm using 32 bit intel, gentoo linux, jdk6 with no problems. My applications only use a serial port, though, nothing on the parallel port. Mike From falko.guderian at gmx.de Wed Mar 21 08:17:35 2007 From: falko.guderian at gmx.de (Falko Guderian) Date: Wed, 21 Mar 2007 15:17:35 +0100 Subject: [Rxtx] RXTX binaries for SH4 Message-ID: <46013E7F.40102@gmx.de> Dear developers, I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no possiblities to compile the source code. Better, I'm not able to do this at the moment. Can you provide me with rxtxSerial.dll (SH4) in the rxtx-2.1-8-testing version? (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) The reason for the testing version is I need custom baud rates. Thanks for help. Kind regards, Falko Guderian From tjarvi at qbang.org Wed Mar 21 21:38:37 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Mar 2007 21:38:37 -0600 (MDT) Subject: [Rxtx] RXTX binaries for SH4 In-Reply-To: <46013E7F.40102@gmx.de> References: <46013E7F.40102@gmx.de> Message-ID: On Wed, 21 Mar 2007, Falko Guderian wrote: > Dear developers, > > I would like to connect to COM port on WinCE 5.0 and SH4 CPU. I have no > possiblities to compile the source code. Better, I'm not able to do this > at the moment. Can you provide me with rxtxSerial.dll (SH4) in the > rxtx-2.1-8-testing version? > (ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing/) > > The reason for the testing version is I need custom baud rates. > > Thanks for help. > Hi Falko WinCE binary format is not supported by gcc. That makes compiling limited to those familiar with the WinCE tools. I hope someone is able to provide them for you but it is not likely. WinCE has been compiled by others in the past but rxtx.org builds have never included WinCE. There is some information with the source concerning WinCE builds if you decide to do it. We can share your results too if you like. The source in the WinCE has never been updated for the custom baud rate. That would need changes from the main source I presume. If you look at the source, you will note that Michal Hobot created a mini fork in the source to handle wince but it has not been updated for 3 years. -- Trent Jarvi tjarvi at qbang.org From Adrien.TOS at ingenico.com Thu Mar 22 07:08:55 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Thu, 22 Mar 2007 14:08:55 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Hi everybody, Do you have any comments on this issue? Thanks! AT ________________________________ De : Adrien TOS Envoy? : vendredi 16 mars 2007 12:11 ? : 'rxtx at qbang.org' Cc : Adrien TOS Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070322/2306c538/attachment-0006.html From jeremy.reeve at zen.co.uk Mon Mar 19 07:36:04 2007 From: jeremy.reeve at zen.co.uk (Jeremy S. Reeve) Date: Mon, 19 Mar 2007 13:36:04 +0000 Subject: [Rxtx] rxtx failing to compile on Fedora Core 6 Message-ID: <1174311364.21865.6.camel@d9thc> When trying to compile latest source : rxtx-2.1-7r2 I get the following when running configure: ---------------- checking os.version 2.6.18-1.2200.fc5smp WARNING: configure is having a hard time determining which directory contains the file jni_md.h. Edit Makefile and fix the variable JAVANATINC to point to the correct directory. The following options are available: /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/ /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/linux/ If there are more than one option available the first was selected. WARNING: Kernel include files do not match the current kernel configure: creating ./config.status ------------------------ which seems OK checking the resultant Makefile but when attempting to build with gmake install I get the following output : ---------------------- 34 problems (34 warnings)/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/javah -classpath .:/home/jsr/rxtxsrc/rxtx-2.1-7r2:/home/jsr/rxtxsrc/rxtx-2.1-7r2/src:/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/ext/RXTXcomm.jar -d i686-pc-linux-gnu -jni `(for i in CommDriver CommPortEnumerator CommPortIdentifier CommPort CommPortOwnershipListener Configure I2C I2CPortEvent I2CPortEventListener I2CPort LPRPort NoSuchPortException ParallelPortEvent ParallelPortEventListener ParallelPort PortInUseException Raw RawPortEvent RawPortEventListener RawPort RS485 RS485PortEvent RS485PortEventListener RS485Port RXTXCommDriver RXTXPort RXTXVersion SerialPortEvent SerialPortEventListener SerialPort UnsupportedCommOperationException UnSupportedLoggerException Zystem;do \ if grep > /dev/null native.* \( /home/jsr/rxtxsrc/rxtx-2.1-7r2/./src/$i.java; then \ echo gnu.io.$i; \ fi; \ done)` i686-pc-linux-gnu/gnu_io_CommPortIdentifier.h: No such file or directory make: *** [/home/jsr/rxtxsrc/rxtx-2.1-7r2/gnu/io/CommDriver.class] Error 1 ------------------------ Any ideas or pointers? Regards, Jeremy From tjarvi at qbang.org Sat Mar 24 08:12:54 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 Mar 2007 08:12:54 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > From Adrien.TOS at ingenico.com Sat Mar 24 11:53:22 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Sat, 24 Mar 2007 18:53:22 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> I do not have the threshold setting enabled, I have explicitely disabled it with: port_.disableReceiveThreshold(); I have also run the same tests with the threshold setting enabled, but they also fail in the same way as described below. So it seems there is a problem with timeout handling on Win32? ________________________________ From: rxtx-bounces at qbang.org on behalf of Trent Jarvi Sent: Sat 3/24/2007 3:12 PM To: RXTX Developers and Users Subject: Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad The behavior of timeout depends upon the setting of the threshold. Do you have the threshold setting? On Thu, 22 Mar 2007, Adrien TOS wrote: > Hi everybody, > > > > Do you have any comments on this issue? > > > > Thanks! > > AT > > > > ________________________________ > > De : Adrien TOS > Envoy? : vendredi 16 mars 2007 12:11 > ? : 'rxtx at qbang.org' > Cc : Adrien TOS > Objet : [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad > > > > Hi, > > > > First, here is our testing environment: > > > > rxtx : rxtx-2.1-7-bins-r2 > > OS : Win XP > > JDK : 1.5 > > > > We run into problems with the receive timeout precision of the rxtx library. > > > > Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. > > > > Here is the test: > > > > First we set the receive timeout by calling: > > > > port_.enableReceiveTimeout(timeout); > > > > Then we wait for some data: > > > > port_.getInputStream().read(buffer); > > > > Test 1: wait for incoming data for 1000 ms (1 sec) > > Result: OK, read() returns after 1015 ms > > > > Test 2: wait for incoming data for 10000 ms (10 secs) > > Result: OK, read() returns after 10005 ms > > > > Test 3: wait for incoming data for 30000 ms (30 secs) > > Result: KO, read() returns after 30908 ms > > > > Test 4: wait for incoming data for 50000 ms (50 secs) > > Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. > > > > Test 4: wait for incoming data for 60000 ms (1 minute) > > Result: KO, read() returns after 61913 ms > > > > Test 5: wait for incoming data for 120000 ms (2 minutes) > > Result: KO, read() returns after 123492 ms > > > > Test 6: wait for incoming data for 180000 ms (3 minutes) > > Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. > > > > Test 7: wait for incoming data for 240000 ms (4 minutes) > > Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. > > > > Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); > > Result: KO, read() returns immediately! <== should wait forever until data comes in? > > > > Have you ever experienced such problems? > > > > Is this a known bug and are there any possible workarounds? > > > > Thanks and regards, > > AT > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 8312 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20070324/f9e39c9b/attachment-0006.bin From greg.johnson at manchester.ac.uk Sun Mar 25 13:41:36 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Sun, 25 Mar 2007 21:41:36 +0200 Subject: [Rxtx] Mac intel weirdness Message-ID: Hi folks, I'm trying to get rxtx to work on my macbook pro with a USB-serial dongle on it. I am using the 2.1-8 code from the CVS (though it seems to report itself as 2.1-7: makes it difficult to prove to oneself that the changes have 'taken'! - line 4210 in SerialImp.c, line 40 in RXTXVersion.java) I am trying the 2.1-8 because of horrible lock problems in 2.1-7. However, the serialport closure code seems to be broken - it won't close because it believes the (previously opened!) port doesn't exist. Here is what I'm trying: 0. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "false" 1. Open a port Serialport serialport = (SerialPort) commportidentifier.open ("test",100); 2. Talk to a device ... 3. Close port serialport.close(); 4. Show port ownership System.out.println(commportidentifier.isCurrentlyOwned()); // "true" - why is this? 5. Try to reopen port Serialport serialport2 = (SerialPort) commportidentifier.open("test", 100); throws PortInUseException. I've dug around a bit in the source, and it seems the SerialPort.close () should call the CommPortIdentifier.internalClosePort() (line 67 of CommPort.java). However, I crash out with the NoSuchPortException when getPortIdentifier is called. Which seems quite weird to me, seeing as it is called on this - which was create just beforehand. Does anyone know how to fix this? Cheers, greg From knute at frazmtn.com Sat Mar 24 10:32:38 2007 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 24 Mar 2007 09:32:38 -0700 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc>, Message-ID: <4604F036.17833.135298@knute.frazmtn.com> > >The behavior of timeout depends upon the setting of the threshold. Do you >have the threshold setting? > This is the same bug I reported last fall. There was a fellow that sent me an email asking if it had been fixed. I told him I didn't think so. He got somebody to write a fix for him but I have not been able to contact him again for the actual changes. The inaccurate timeout and the failure of blocking when no timeouts are set is a serious bug in my humble opinion and renders the software unusable for my applications. I'd really like to have an alternative to the Sun comm api but there just isn't one that I know of. -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Mar 26 16:17:00 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 26 Mar 2007 16:17:00 -0600 (MDT) Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> References: <72CF8F2B2766084DBD7AEAFCAE4A3B7903DC0C1C@frsnprexc1.usr.ingenico.loc> <72CF8F2B2766084DBD7AEAFCAE4A3B79044655@frsnprexc1.usr.ingenico.loc> Message-ID: >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. From ra85551 at gmail.com Tue Mar 27 10:18:36 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Tue, 27 Mar 2007 20:18:36 +0400 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Ultimately I found a solution. At first, that wasn't actually the VMWare + WinXP + RXTX issue, that was WinXP + RXTX issue. But on pure XP it sometimes workes, sometimes not, while under VMWare I had never seen my snippet working at all. SimpleSnuV1.java would not help me, because there is only one line I missed, and SimpleSnuV1.java also doesn't contain it! It is as follows: serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_OUT | SerialPort.FLOWCONTROL_RTSCTS_IN); Thank you for your attention. -- Pavel Parkhomenko From griff at op.pl Wed Mar 28 01:28:19 2007 From: griff at op.pl (griff@op.pl) Date: Wed, 28 Mar 2007 09:28:19 +0200 Subject: [Rxtx] No blocking read on Windows. Message-ID: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/5d07d571/attachment-0006.html -------------- next part -------------- Hi, I have problem that InputStram.read() (SerialPort)?returns -1 instead blocking and waiting for data. I found that this problem was ?known in 2005 : ? >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > >> Hi Trent >> >> Thanks for the fast response. >> Here's a Q&D test program for the blocking read on windows that just >> attempts to read one byte, and prints the resulting byte. On my system it >> returns -1, where I expect that it keeps waiting for data. >> >This isn't happening on Linux so the bug is in src/termios.c.? I'll have >something this weekend to fix that. I'm using RXTX 2.1.7r2 and the problem still is here. Im using Windows XP and java 1.5 disableReciveTimeout() and disableReciveTreshhold() dont help. ? best regards ? Piotr Zielniok From Adrien.TOS at ingenico.com Wed Mar 28 01:40:46 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Wed, 28 Mar 2007 09:40:46 +0200 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad In-Reply-To: Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903E88880@frsnprexc1.usr.ingenico.loc> Looking at the code, it seems there is no support for infinite timeout? And maybe the count++ < 20 condition is breaking out of the loop too early? The only condition to break out of the loop should either be the timeout has expired or the number of requested bytes has been received. -----Message d'origine----- De : rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] De la part de Trent Jarvi Envoy? : mardi 27 mars 2007 00:17 ? : RXTX Developers and Users Objet : Re: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad >> Test 6: wait for incoming data for 180000 ms (3 minutes) >> >> Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. >> >> >> >> Test 7: wait for incoming data for 240000 ms (4 minutes) >> >> Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. >> With these cases, we should be able to examine just the serialImp.c code for timeout. The values are easily stored in an int so I do not think there is any wrap around issues. if (timeout >= 0) start = GetTickCount(); while( bytes < length && count++ < 20 ) /* && !is_interrupted( eis ) )*/ { if (timeout >= 0) { now = GetTickCount(); if ( now-start >= timeout ) { eis->eventflags[SPE_DATA_AVAILABLE] = flag; return bytes; } } FD_ZERO(&rset); FD_SET(fd, &rset); if (timeout >= 0){ timeLeft = timeout - (now - start); tv.tv_sec = timeLeft / 1000; tv.tv_usec = 1000 * ( timeLeft % 1000 ); tvP = &tv; } else{ tvP = NULL; } /* FIXME HERE Trent */ #ifndef WIN32 ret = SELECT( fd + 1, &rset, NULL, NULL, tvP ); #else ret = 1; #endif /* WIN32 */ if (ret == -1){ report( "read_byte_array: select returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ ... /* no new data */ else { /* usleep(10); */ usleep(1000); } Maybe someone else sees something there but it looks sane to me. The windows case is not running select. I recall that I was having problems with select between the eventLoop and other threads so it is disabled on windows. It will sleep for a short period of time and then read again on windows. If read is returning an error, then we would break out. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From j.kenneth.gentle at acm.org Wed Mar 28 06:44:15 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 28 Mar 2007 08:44:15 -0400 Subject: [Rxtx] No blocking read on Windows. In-Reply-To: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> References: <20070328072824Z1183679-15312+3@kps7.test.onet.pl> Message-ID: <200703281844.l2SIiITW028614@qbang.org> Just another "ME TOO!" - I'm seeing this problem on Windows XP, jre for windows XP/Embedded. I cranked receiveTimeout up to Integer.MAX_INT, but it doesn't seem to wait that long At 03:28 2007-03-28, you wrote: >Hi, >I have problem that InputStram.read() (SerialPort) returns -1 >instead blocking and waiting for data. I found that this problem >was known in 2005 : > > >On Fri, 21 Jan 2005, Dierikx, Marc wrote: > > > >> Hi Trent > >> > >> Thanks for the fast response. > >> Here's a Q&D test program for the blocking read on windows that just > >> attempts to read one byte, and prints the resulting byte. On my system it > >> returns -1, where I expect that it keeps waiting for data. > >> > > >This isn't happening on Linux so the bug is in src/termios.c. I'll have > >something this weekend to fix that. > >I'm using RXTX 2.1.7r2 and the problem still is here. >Im using Windows XP and java 1.5 >disableReciveTimeout() and disableReciveTreshhold() dont help. > >best regards > >Piotr Zielniok > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From greg.johnson at manchester.ac.uk Wed Mar 28 14:43:29 2007 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Wed, 28 Mar 2007 22:43:29 +0200 Subject: [Rxtx] Cannot close and reopen serial port Message-ID: <377F9765-7A9D-4CE9-9176-FFB63A2594F0@manchester.ac.uk> Dear all, It appears I cannot close a port properly: SerialPort serialport = portid.open("myprog",100); // do some stuff, all works fine serialport.close(); // all seems fine but... SerialPort sp2 = portid.open("myprog",100); throws PortInUseException. And when I dig into the rxtx code, I find in CommPort.java, in close(): CommPortIdentifier cp = CommPortIdentifier.getPortIdentifier(this); (line 64 or there abouts) but this throws a NoSuchPortException which is caught but ignored (line 74ish). Can anyone suggest how this could happen: a port that was valid, opened, and used, throws a NSPE when it comes to closing it? I'm pulling my (remaining) hair out over this one! Cheers, greg PS And thanks for RXTX - it's great to have! PPS (21.-7. winxp/osx both, java 1.5) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070328/c28852fc/attachment-0006.html From rxtx at vrijheidslaan.net Fri Mar 30 16:52:50 2007 From: rxtx at vrijheidslaan.net (Rob) Date: Fri, 30 Mar 2007 22:52:50 -0000 Subject: [Rxtx] Cvs Question Message-ID: <61896.80.126.150.87.1175295162.squirrel@webmail.provalue.nl> Hi There, Im trying to get the latest version to work on mac osx. Problem is that i can't checkout version 2.1.8. Probably my fault but can some one please give me the alternative commands for: [user at myhost]$ export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot [user at myhost]$ cvs login Thanx, Rob From ra85551 at gmail.com Thu Mar 1 03:47:06 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Thu, 1 Mar 2007 13:47:06 +0300 Subject: [Rxtx] enableReceiveTimeout() issue Message-ID: Hello, world! I found a limitation of 16300 ms for CommPort's enableReceiveTimeout() method, while in original javax.comm docs there are no any references to that. Is that a bug or feature? I actually need longer timeouts sometimees. -- Pavel Parkhomenko From lyon at docjava.com Thu Mar 1 07:54:17 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 01 Mar 2007 09:54:17 -0500 Subject: [Rxtx] parametric singleton design pattern In-Reply-To: References: <22d55aea0702081207q5e7f6785l352d498d6f5f9fb1@mail.gmail.com> <22d55aea0702100034o3bcf42f3j1d1a6257029a67b0@mail.gmail.com> Message-ID: Hi All, I have been thinking about the use of a design pattern to cache resources that are consumed by processes. Toward that end, I have arrived at a parametric singleton design pattern, which I mentioned on this list some time ago. The idea has been published at: http://www.jot.fm/issues/issue_2007_03/column2 I can't help but think that there should be an API available for dealing with the tracking of serial port usage. Perhaps it is a kind of resource manager called the: SerialPortManager basic prototypes already exist in this vain. See, for example: http://www.ce.rit.edu/research/projects/2005_fall/rt_poolsystem/doc/PoolMon/SerialPortManager.html http://www.eventhelix.com/RealtimeMantra/PatternCatalog/serial_port_design_pattern.htm And others shown by a google search on "SerialPortManager" Cheers! - Doug From Eric.Arseneau at sun.com Thu Mar 1 10:15:03 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:15:03 -0800 Subject: [Rxtx] Any known Java 6 issues with RXTX 2.1-7r2 ? Message-ID: <45E70A17.1060206@sun.com> I just did a test on a recent build of Solaris 11 x86 and it seems that I can connect to my serial device fine when Java 5 is the default, but when Java 6 is the default, no go. Any information ? From Eric.Arseneau at sun.com Thu Mar 1 10:19:58 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Thu, 01 Mar 2007 09:19:58 -0800 Subject: [Rxtx] Mac OS X and missing data Message-ID: <45E70B3E.7040908@sun.com> We have a device which is USB based but presents itself as a serial port to a machine. On my MacBook Pro I can get excellent throughput if I get my device to send data as quickly as possible. On the desktop side, if I do an type of disk IO to log the data I get, I end up with some missing data at some point. I hooked up a USB analyzer and did confirm that all the data is sent as expected to the desktop from the device. I found a work around for this, buffer the data in memory and only write the data out when I've received it all. However, when the same code and same device is attempted on a co-workers MacBook Pro (same hardware specs), I get errors and must slow down dramatically the device side's sending of data. Any ideas/recommendations on what I can do to get rid of this error ? From what I can tell, it seems that RXTX is not able to wake up to the interrupts coming in indicating data is ready, quickly enough, is there anything I can do ? From chinkaiw at hotmail.com Fri Mar 2 00:57:43 2007 From: chinkaiw at hotmail.com (Wang Chinkai) Date: Fri, 02 Mar 2007 07:57:43 +0000 Subject: [Rxtx] dynamic detect rs232 port Message-ID: Hi all I have a question about detecting rs232 port dynamicly. I have to aceess some port and detect rs232 port at the same time. Some usb device simulates rs232 port , and I can not know what the port name it gets until it connects,so I have to detect it dynamic,but I have to access another rs232 device at the same time. I found a problem. If I use CommPortIdentifier.getPortIdentifiers() to get new port list , and the other rs232 access function will not close port correctly. So , How can I solve it . Thanks. _________________________________________________________________ ?? 2GB ???? Windows Live Mail ????????????? http://ideas.live.com/programpage.aspx?versionid=5d21c51a-b161-4314-9b0e-4911fb2b2e6d From eu259473 at tele2.it Fri Mar 2 06:16:40 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 02 Mar 2007 14:16:40 +0100 Subject: [Rxtx] rxtx on HP tru 64 unix Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070302/706c7a70/attachment-0007.html From tjarvi at qbang.org Fri Mar 2 08:39:33 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 08:39:33 -0700 (MST) Subject: [Rxtx] rxtx on HP tru 64 unix In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, "Giuseppe Marchese" wrote: > Hi > > I try to install rxtx on hp tru 64 but make fails, > There are somebody that do the same and work. > > > Sorry for may english! > > Hi Giuseppe Could you provide a log of the failure? script ./configure make # use gnu make exit The information will be in the typescript created. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Mar 2 19:56:52 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 2 Mar 2007 19:56:52 -0700 (MST) Subject: [Rxtx] dynamic detect rs232 port In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, Wang Chinkai wrote: > Hi all > > I have a question about detecting rs232 port dynamicly. > > I have to aceess some port and detect rs232 port at the same time. > Some usb device simulates rs232 port , and I can not know > what the port name it gets until it connects,so I have to detect it > dynamic,but I have to access > another rs232 device at the same time. > > I found a problem. Hi Wang This is a known problem. The code is braindead there. In fact there needs to be events even in a rudamentary way when you add a usb dongle. I'm burried in tasks not far from rxtx but not in rxtx. I can't get to the problem but we would accept patches if you dig into it. [I'm getting to the license question earlier too; I don't have another 10%] -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Fri Mar 2 23:19:01 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 01:19:01 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Hi, Under ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable USB -> serial converter(using virtual com port drivers), with using example code pretty much straight out of http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port opens fine, enumerations all work, etc. My application calls for a large amount of data to be transferred in a short amount of time at 2,000,000 baud. My hardware sends approximately 15,232 bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL converter work fine, and the application works using C++. In C++, I do a hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); to open the port, and a boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); to read the port. The variable buffer fills with the 15238 bytes, and returns. If I do a resultz = is.read(cbuf,0,15238); in java with RXTX where is = new BufferedReader(new InputStreamReader(port.getInputStream())); and where resultz is an int, and cbuf is a char [] cbuf, resultz gets EXACTLY 3968 bytes the first time called. If I call it multiple times, I get roughly 11k total(less than what is sent), never more than the 3968 bytes per is.read() call. My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 bytes. I've played with inputbuffersize, receive threshold, receivetimeout, and so on. The FTDI virtual com port drivers that I'm using are rock solid, and have had zero problems with them using a variety of applications, some of my own, some professionally written, etc. No flow control is used anyplace, no RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. No exceptions are being thrown. What am I doing wrong, and what I can adjust to receive the full 15k bytes in one single read? Thanks! Keith From Eric.Arseneau at sun.com Fri Mar 2 23:32:07 2007 From: Eric.Arseneau at sun.com (Eric Arseneau) Date: Fri, 02 Mar 2007 22:32:07 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <45E91667.20501@sun.com> This is the same type of thing that is happening to me on Mac OS X and does not seem to behave the same on different machines. I posted a day or two ago on this with subject "Mac OS X and missing data". Would love to hear if there is a solution to this :) From tjarvi at qbang.org Sat Mar 3 10:54:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 10:54:17 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > Hi, > > Under > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > with NetBeans IDE 5.5, java 1.6.0, Windows 2000, and using a 3mbps capable > USB -> serial converter(using virtual com port drivers), with using example > code pretty much straight out of > http://en.wikibooks.org/wiki/Serial_Programming:Serial_Java , the port > opens fine, enumerations all work, etc. > > My application calls for a large amount of data to be transferred in a short > amount of time at 2,000,000 baud. My hardware sends approximately 15,232 > bytes, with the PC and RXTX being the receiver. The hardware and USB->TTL > converter work fine, and the application works using C++. > > In C++, I do a > > hCom = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0,NULL, > OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); > > to open the port, and a > > boolret = ReadFile(hCom, &buffer, 15238, &numberofbytesread, NULL); > > to read the port. > > The variable buffer fills with the 15238 bytes, and returns. > > If I do a > > resultz = is.read(cbuf,0,15238); in java with RXTX > > where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > > and where resultz is an int, and cbuf is a char [] cbuf, resultz gets > EXACTLY 3968 bytes the first time called. If I call it multiple times, I get > roughly 11k total(less than what is sent), never more than the 3968 bytes > per is.read() call. > > My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 > bytes. > > I've played with inputbuffersize, receive threshold, receivetimeout, and so > on. The FTDI virtual com port drivers that I'm using are rock solid, and > have had zero problems with them using a variety of applications, some of my > own, some professionally written, etc. No flow control is used anyplace, no > RTS/CTS, no XON/XOFF, etc. Data is binary data. Normal 8-n-1 stuff. > > No exceptions are being thrown. > > What am I doing wrong, and what I can adjust to receive the full 15k bytes > in one single read? > > Thanks! > Hi Keith I would expect a 20 meg application is going to have different behavior with the OS than a smaller application with respect to the kernel memory managment, schedualing, ... Something subtle could be causing problems. With respect to the recieve timeout and threshold, if you set the timeout to zero and the threshold to the size of data you expect, read should not return until it get that data. You may try with a stand alone application that tests just that with the C/C++ API. If the read is returning with less data when tested for short reads, you have found a bug in the device driver more than likely. The USB dongle vendor would probably be interested in knowing about this. As mentioned, these devices are getting very good; almost bug free. I suspect you found a bug though if you did use the threshold and timeout properly. The missing data is typical when not using flow control. When the OS buffering fills, the hardware will start dropping bytes. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:38:52 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:38:52 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes Message-ID: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> update: I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now instead of 3968. This makes sense. 128 bytes of overhead + 3968 bytes of data = 4096 transfer size 32 bytes of overhead + 992 bytes of data = 1024 transfer size. 1/4 the data = 1/4 the overhead. I rearranged my reading like so: resultz = is.read(cbuf,0,3968); resultz = is.read(cbuf,3968,3968); resultz = is.read(cbuf,7936,3968); while (!(is.ready())); // wait for ready resultz = is.read(cbuf,11904,3334); and this grabs 15,238 bytes total. BUT, I still have the quandry of the screwed up multi-bytes. I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. Approx 8% of the data. The bad bytes always seem to take the flavor of 0x2018, 0x2019, x2022, x2030, x201d. Are these maybe errors and I don't know what they enumerate to? I still can't believe some other layer isn't handling putting those bytes together all in one stream for me. Thanks Keith ----- Original Message ----- From: "Keith" To: "Bob Jacobsen" ; "RXTX Developers and Users" Sent: Saturday, March 03, 2007 11:26 AM Subject: Re: [Rxtx] is.read() only returning 3968 bytes > Bob, > > > Interesting numerical coincidence is that (max USB transfer) - (what > > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > > needed to transfer that much data. > > I was thinking along the same lines. I don't know USB well, but I do know > that those numbers were close enough to warrant investigating the > relationship between them. > > > I think what you're seeing is the internal buffering of the USB data > > stream. You'll need some form of higher-level buffering to smooth > > that out. > > Shouldn't the InputStreamReader() and BufferedReader() provide this type of > buffering? Isn't that the idea behind those? > > > All hypotheses need to be tested. In this case, a test would be to > > check for missing data. If this idea is right, you'll get _all_ the > > data, but you won't be missing characters. > > I did start looking at the data. -- I'm getting weird results. > > I tried this: > > loopzz = 0; > > for (looptwo = 0; looptwo < 100000; looptwo++) { > while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > > }} > > So I'm reading one character at a time. The good news is that loopzz is > exactly 15238 at the end of the routine, which is perfectly correct. I > picked looptwo value out of thin air. > > The weird results come in terms of the values, the data isn't correct at > least in one case. Look here: > > 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > > This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). > But the 0x89 was replaced by 0x2030. Why the heck would the returned value > be 0x2030?? Why is the returned byte completely out of range? Why the > multibyte return? > > From InputStream in the API: > > read > public abstract int read() > throws IOExceptionReads the next byte of data from the > input stream. The value byte is returned as an int in the range 0 to 255. If > no byte is available because the end of the stream has been reached, the > value -1 is returned. This method blocks until input data is available, the > end of the stream is detected, or an exception is thrown. > Value should be 0-255. > > > In my application time is really critical, reading 1 byte at a time is > probably not going to work. > > Thanks Eric & Bob for looking at this. > > Keith > From tjarvi at qbang.org Sat Mar 3 12:52:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 12:52:27 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: On Sat, 3 Mar 2007, Keith wrote: > update: > > I changed USB transfer size from 4096 -> 1024. read() returns 992 bytes now > instead of 3968. > > This makes sense. > > 128 bytes of overhead + 3968 bytes of data = 4096 transfer size > 32 bytes of overhead + 992 bytes of data = 1024 transfer size. > > 1/4 the data = 1/4 the overhead. > > I rearranged my reading like so: > > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT consistent. > Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? > > I still can't believe some other layer isn't handling putting those bytes > together all in one stream for me. > The layer for this in Serial land is flow control. Software and hardware flow control prevent the overruns you observe. -- Trent Jarvi tjarvi at qbang.org From keithvz at verizon.net Sat Mar 3 12:54:41 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 14:54:41 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <001a01c75dcd$c8802a70$6600a8c0@jbh757ktruws7g> Trent, Thanks for taking the time to reply. > I would expect a 20 meg application is going to have different behavior > with the OS than a smaller application with respect to the kernel memory > managment, schedualing, ... Something subtle could be causing problems. Well, at least I know the VCP drivers, the OS, etc can handle 2mbps reliably. Without hiccuping or dropping bytes. The C++ code works reliably without flow control. > The missing data is typical when not using flow control. When the OS > buffering fills, the hardware will start dropping bytes. I'm actually not getting MISSING data, I'm getting CORRUPTED data. If you look at my most recent post, I'm getting these bad bytes in place of the correct values: 0x2018, 0x2019, x2022, x2030, x201d. Why would is.read() return values not in the range of 0-255 ? Thanks. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 08:59:14 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 07:59:14 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: At 1:19 AM -0500 3/3/07, Keith wrote: >If I do a > >resultz = is.read(cbuf,0,15238); in java with RXTX > >where is = new BufferedReader(new InputStreamReader(port.getInputStream())); > >and where resultz is an int, and cbuf is a char [] cbuf, resultz gets >EXACTLY 3968 bytes the first time called. If I call it multiple times, I get >roughly 11k total(less than what is sent), never more than the 3968 bytes >per is.read() call. > >My USB to serial converter "USB Transfer Size" is set to the maximum of 4096 >bytes. Interesting numerical coincidence is that (max USB transfer) - (what you get) = 4096-3968 = 128 bytes is (almost) the size of the headers needed to transfer that much data. I think what you're seeing is the internal buffering of the USB data stream. You'll need some form of higher-level buffering to smooth that out. All hypotheses need to be tested. In this case, a test would be to check for missing data. If this idea is right, you'll get _all_ the data, but you won't be missing characters. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 09:26:14 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 11:26:14 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> Message-ID: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Bob, > Interesting numerical coincidence is that (max USB transfer) - (what > you get) = 4096-3968 = 128 bytes is (almost) the size of the headers > needed to transfer that much data. I was thinking along the same lines. I don't know USB well, but I do know that those numbers were close enough to warrant investigating the relationship between them. > I think what you're seeing is the internal buffering of the USB data > stream. You'll need some form of higher-level buffering to smooth > that out. Shouldn't the InputStreamReader() and BufferedReader() provide this type of buffering? Isn't that the idea behind those? > All hypotheses need to be tested. In this case, a test would be to > check for missing data. If this idea is right, you'll get _all_ the > data, but you won't be missing characters. I did start looking at the data. -- I'm getting weird results. I tried this: loopzz = 0; for (looptwo = 0; looptwo < 100000; looptwo++) { while (is.ready()) { cbuf[loopzz] = (char) is.read(); loopzz++; }} So I'm reading one character at a time. The good news is that loopzz is exactly 15238 at the end of the routine, which is perfectly correct. I picked looptwo value out of thin air. The weird results come in terms of the values, the data isn't correct at least in one case. Look here: 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). But the 0x89 was replaced by 0x2030. Why the heck would the returned value be 0x2030?? Why is the returned byte completely out of range? Why the multibyte return? >From InputStream in the API: read public abstract int read() throws IOExceptionReads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown. Value should be 0-255. In my application time is really critical, reading 1 byte at a time is probably not going to work. Thanks Eric & Bob for looking at this. Keith From Bob_Jacobsen at lbl.gov Sat Mar 3 14:44:50 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 13:44:50 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: Java's "char" type is Unicode. I think what you're seeing is a bug in the byte -> Unicode translation. 0x2018, 0x2019 are the curly open and close quotes. There used to be (and might still be) bugs in the conversion of these in a couple of libc versions. Some of the ASCII -> ISO and ISO -> ASCII routines were a little over-ambitious with respect to handling the open and close quotes, and tried to convert them to the "curly" form inappropriately. Try _not_ casting it to char. Bob At 11:26 AM -0500 3/3/07, Keith wrote: >Bob, > >> Interesting numerical coincidence is that (max USB transfer) - (what >> you get) = 4096-3968 = 128 bytes is (almost) the size of the headers >> needed to transfer that much data. > >I was thinking along the same lines. I don't know USB well, but I do know >that those numbers were close enough to warrant investigating the >relationship between them. > >> I think what you're seeing is the internal buffering of the USB data >> stream. You'll need some form of higher-level buffering to smooth >> that out. > >Shouldn't the InputStreamReader() and BufferedReader() provide this type of >buffering? Isn't that the idea behind those? > >> All hypotheses need to be tested. In this case, a test would be to >> check for missing data. If this idea is right, you'll get _all_ the >> data, but you won't be missing characters. > >I did start looking at the data. -- I'm getting weird results. > >I tried this: > >loopzz = 0; > >for (looptwo = 0; looptwo < 100000; looptwo++) { >while (is.ready()) { > > cbuf[loopzz] = (char) is.read(); > loopzz++; > >}} > >So I'm reading one character at a time. The good news is that loopzz is >exactly 15238 at the end of the routine, which is perfectly correct. I >picked looptwo value out of thin air. > >The weird results come in terms of the values, the data isn't correct at >least in one case. Look here: > >0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x2030) 0x44 (0x2030) > >This *should* be 0x44 0xff 0xff 0xaa 0xaa 0xaa 0xaa 0x44 (0x89) 0x44 (0x89). >But the 0x89 was replaced by 0x2030. Why the heck would the returned value >be 0x2030?? Why is the returned byte completely out of range? Why the >multibyte return? > >>From InputStream in the API: > >read >public abstract int read() > throws IOExceptionReads the next byte of data from the >input stream. The value byte is returned as an int in the range 0 to 255. If >no byte is available because the end of the stream has been reached, the >value -1 is returned. This method blocks until input data is available, the >end of the stream is detected, or an exception is thrown. >Value should be 0-255. > > >In my application time is really critical, reading 1 byte at a time is >probably not going to work. > >Thanks Eric & Bob for looking at this. > >Keith > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From keithvz at verizon.net Sat Mar 3 15:10:11 2007 From: keithvz at verizon.net (Keith) Date: Sat, 03 Mar 2007 17:10:11 -0500 Subject: [Rxtx] is.read() only returning 3968 bytes References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> Message-ID: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Bob said ..... > Java's "char" type is Unicode. I think what you're seeing is a bug > in the byte -> Unicode translation. Bob -- I think you hit the nail on the head. I was just coming to the same realization here. I knew that something funny was going on because the same bytes always got "corrupted." I'm pretty sure its in the InputStreamReader() functionality where the conversion junk is happening. Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. I don't know if simply changing the cast is going to work. Since the conversion is happening upstream (pun intended), I don't think my cast is doing this. Also I think the compiler forced me to use the cast. I'm still playing around, and I'll report back once I nail it down. Thanks!! Keith From tjarvi at qbang.org Sat Mar 3 15:59:46 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 Mar 2007 15:59:46 -0700 (MST) Subject: [Rxtx] Win64 rxtx Testers? Message-ID: I have compiled win64 binaries of rxtx. Are there any users interested in testing them? If so, I'll look into putting them on the web site. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Mar 3 15:35:06 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 3 Mar 2007 14:35:06 -0800 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: Because of this and similar problems, JMRI does all it's serial IO using +only+ byte values. It's a but of a pain, as Java wants to go to char and int types a little too aggressively, but it does solve the "uncontrolled conversions" problems. Bob At 5:10 PM -0500 3/3/07, Keith wrote: >Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > >Bob -- I think you hit the nail on the head. > >I was just coming to the same realization here. I knew that something funny >was going on because the same bytes always got "corrupted." > >I'm pretty sure its in the InputStreamReader() functionality where the >conversion junk is happening. > >Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > >I don't know if simply changing the cast is going to work. Since the >conversion is happening upstream (pun intended), I don't think my cast is >doing this. Also I think the compiler forced me to use the cast. -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mark at mdsh.com Sun Mar 4 11:01:33 2007 From: mark at mdsh.com (Mark Himsley) Date: Sun, 04 Mar 2007 18:01:33 +0000 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> References: <000b01c75dcb$93183550$6600a8c0@jbh757ktruws7g> Message-ID: <5C01AC72C200388815C04982@bedroom.mdsh.local> On 03 March 2007 14:38 -0500 Keith wrote: > resultz = is.read(cbuf,0,3968); > resultz = is.read(cbuf,3968,3968); > resultz = is.read(cbuf,7936,3968); > > while (!(is.ready())); // wait for ready > resultz = is.read(cbuf,11904,3334); > > and this grabs 15,238 bytes total. > > BUT, I still have the quandry of the screwed up multi-bytes. > > I'm getting roughly 1,000 bad bytes. The number of bytes is NOT > consistent. Approx 8% of the data. > > The bad bytes always seem to take the flavor of > > 0x2018, 0x2019, x2022, x2030, x201d. > > Are these maybe errors and I don't know what they enumerate to? It looks like you need to use DataInputStream and DataOutputStream. -- Mark Himsley From tjarvi at qbang.org Sun Mar 4 11:35:08 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 11:35:08 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" > > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > > * Line #21 - Not sure if you need a (TM) mark for > the term "Sun" > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > OK. I'm going through this today. Some groups ask if rxtx could be under their license also. I think this is a good example of why I resist multiple licenses and focus on why the current license may not be usable by them. The RXTX project is a convergence of hobby and commercial interests. I happen to do both right now. The problem with licensing is we have to stay on top of them as they change. Clearly, adding more licenses will not make this easier. I'm acting as the hobby person today. RXTX always favors the hobby people. But as we move forward, I'm going to need to bring this to lawyers at work and explain to them what is going on. Others here may have to do this also. I don't anticipate problems or unexpected changes. The goal is a consistant, comprehendable and usable license as close to what we have now as possible. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 14:52:10 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 14:52:10 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (1/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: I'm breaking this into two parts. I expect the second part will need more attention. Comments first, then the changed material below. On Tue, 20 Feb 2007, Oberhuber, Martin wrote: > Hi Trent, > > thanks for consolidating the licenses. > Here are some initial comments: > > * Line #1 - Typo - shouldn't it be "controlled interfaces" > instead of "controled" > Thanks > * Line #2, #13 - rxtx - All the rest of the license uses > RXTX capitalized, I believe this should be consistent. > Also, I think that the term "Java" should be capitalized > and might need a (TM) suffix to make Sun happy. OK. RXTX for consitent use. java should not be capitalized because it does not only mean Sun [TM] Java [TM]. An example of this not meaning Java is when people use RXTX with GCJ. > > * Line #3 - Copyright - Aren't there other contributors > in all of RXTX too? I'd be more comfortable with: > "Copyright 1997-2007 by RXTX contributors" > or "Trent Jarvi and RXTX contributors". There are not any contributors that are in all of RXTX yet but I did update the comment to try to reflect the current situation without making it a nightmare to maintain. I looked to see how the Linux kernel does it as a reference point. > > * Line #7 - LGPL Reference - Would it be possible to > add an URL pointing to the LGPL version 2.1 on the > Internet? - Also, you reference LGPL 2.1, but the > copy of LGPL below states "Version 2, June 1991" The URL can be problematic. I have done so below with a time reference. GNU does not provide version information in their URLS. I picture this being a problem when the version 3 comes out. > > * You reference the "GNU Lesser General Public License" > but the verbatim copy below titles it the "GNU > Library General Public License". I believe these > should be consistent. > This will be corrected when the copy is updated to the version linked below. ---------------- begin proposed material involved -------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. ----------------- end proposed material involved -------------------- I'll be looking at the linking issue again next. That should be all that remains other than including the 2.1 version. Let me know if you have problems with anything here. I do not want to dilute the material I post next with these housekeeping tasks. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 4 16:08:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 4 Mar 2007 16:08:36 -0700 (MST) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: For those that are wondering what is going on here, this next bit is the meat of the changes. We agreed a long time ago to put this disclaimer in. We did a so so job. It was in rxtx 2.0, not well written, ... So some groups using rxtx that would like to ship rxtx so users don't need to download, install, go to the mail-list to find why it failed, ... Then their legal teams tell them section 5 paragraph 2 is a show stopper. That was never the intent. Now going through what remains... > and might need a (TM) suffix to make Sun happy. Added disclaimer at the ended 'all trademarks belong...' > * Line #15ff - static vs. dynamic linking - you did > not transcribe the text from the "controlled > interface exception" when writing this text - and > this was good so, because these terms originally > refer to the GPL rather than the LGPL. I think though, > that these 4 lines are the most important ones and > should thus be really really clear. I hope that I > meet your original intent with the following > suggestions: > 1.) Instead of "A program.." it would be better to > say "An exectuable.." in order to be closer to > the LGPL text. OK. As you can see I was trying to adjust GNU text there for the LGPL. > 2.) It would be better to say .. "by being dynamically > linked with it" to clearly indicate that dynamic > linking is meant. The matter of compilation is > already covered by the LGPL so mentioning it again > just leads to confusion. used dynamically linked terminology. > 3.) It would be better to say .. "is considered a > work that uses the library in contrast to section > 5 of the LGPL, so the terms of the LGPL do not > apply to the resulting executable". I tried to address this more upfront with an intent statement. Let me know if you have problems with it. I also tried to make it a little more clear what was derived from the GNU solution by moving the link location closer to GNU's suggestion. > > Note that LGPL section 5 says: ..."is called a > "work that uses the Library". Such a work, in isolation, > is not a derivative work of the Library, and therefore > falls outside the scope of this License." > The next paragraph of the LGPL is exactly the problematic > one that I hope is clarified by the exception terms you > give. > Thats the intent. Here is the combined fixes. Note that only the material in /*-- --*/ is being touched. The new GPL license is there but unmodified. ------------------------ begin proposed new license ------------------- /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Lesser General Public | License as published by the Free Software Foundation; either | version 2.1 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Lesser General Public License for more details. | | An executable that contains no derivative of any portion of RXTX, but | is designed to work with RXTX by being dynamically linked with it, | is considered a "work that uses the Library" subject to the terms and | conditions of the GNU Lesser General Public License. | | The following has been added to the RXTX License to remove | any confusion about linking to RXTX. We want to allow in part what | section 5, paragraph 2 of the LGPL does not permit in the special | case of linking over a controlled interface. The intent is to add a | Java Specification Request or standards body defined interface in the | future as another exception but one is not currently available. | | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface | | As a special exception, the copyright holders of RXTX give you | permission to link RXTX with independent modules that communicate with | RXTX solely through the Sun Microsytems CommAPI interface version 2, | regardless of the license terms of these independent modules, and to copy | and distribute the resulting combined work under terms of your choice, | provided that every copy of the combined work is accompanied by a complete | copy of the source code of RXTX (the version of RXTX used to produce the | combined work), being distributed under the terms of the GNU Lesser General | Public License plus this exception. An independent module is a | module which is not derived from or based on RXTX. | | Note that people who make modified versions of RXTX are not obligated | to grant this special exception for their modified versions; it is | their choice whether to do so. The GNU Lesser General Public License | gives permission to release a modified version without this exception; this | exception also makes it possible to release a modified version which | carries forward this exception. | | You should have received a copy of the GNU Lesser General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA | All trademarks belong to their respective owners. --------------------------------------------------------------------------*/ The original GNU Lesser General Public License Follows. GNU LESSER GENERAL PUBLIC LICENSE Version 2.1, February 1999 Copyright (C) 1991, 1999 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. [This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence the version number 2.1.] Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This license, the Lesser General Public License, applies to some specially designated software packages--typically libraries--of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below. When we speak of free software, we are referring to freedom of use, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish); that you receive source code or can get it if you want it; that you can change the software and use pieces of it in new free programs; and that you are informed that you can do these things. To protect your rights, we need to make restrictions that forbid distributors to deny you these rights or to ask you to surrender these rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library or if you modify it. For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights. We protect your rights with a two-step method: (1) we copyright the library, and (2) we offer you this license, which gives you legal permission to copy, distribute and/or modify the library. To protect each distributor, we want to make it very clear that there is no warranty for the free library. Also, if the library is modified by someone else and passed on, the recipients should know that what they have is not the original version, so that the original author's reputation will not be affected by problems that might be introduced by others. Finally, software patents pose a constant threat to the existence of any free program. We wish to make sure that a company cannot effectively restrict the users of a free program by obtaining a restrictive license from a patent holder. Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license. Most GNU software, including some libraries, is covered by the ordinary GNU General Public License. This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs. When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library. We call this license the "Lesser" General Public License because it does Less to protect the user's freedom than the ordinary General Public License. It also provides other free software developers Less of an advantage over competing non-free programs. These disadvantages are the reason we use the ordinary General Public License for many libraries. However, the Lesser license provides advantages in certain special circumstances. For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License. In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software. For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU operating system, as well as its variant, the GNU/Linux operating system. Although the Lesser General Public License is Less protective of the users' freedom, it does ensure that the user of a program that is linked with the Library has the freedom and the wherewithal to run that program using a modified version of the Library. The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, whereas the latter must be combined with the library in order to run. GNU LESSER GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License Agreement applies to any software library or other program which contains a notice placed by the copyright holder or other authorized party saying it may be distributed under the terms of this Lesser General Public License (also called "this License"). Each licensee is addressed as "you". A "library" means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables. The "Library", below, refers to any such software library or work which has been distributed under these terms. A "work based on the Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term "modification".) "Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library. Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does. 1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) The modified work must itself be a software library. b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change. c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License. d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful. (For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library. In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. 4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange. If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code. 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables. When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law. If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.) Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself. 6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications. You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things: a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.) b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. c) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution. d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place. e) Verify that the user has already received a copy of these materials or that you have already sent this user a copy. For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute. 7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things: a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above. b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work. 8. You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 9. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Library (or any work based on the Library), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Library or works based on it. 10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties with this License. 11. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply, and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 12. If the distribution and/or use of the Library is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Library under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 13. The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation. 14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Libraries If you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the ordinary General Public License). To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Also add information on how to contact you by electronic and paper mail. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the library, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the library `Frob' (a library for tweaking knobs) written by James Random Hacker. , 1 April 1990 Ty Coon, President of Vice That's all there is to it! ------------------------ end of proposed license ------------------ -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sun Mar 4 16:26:04 2007 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 04 Mar 2007 17:26:04 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <45EB558C.3010609@cox.net> Bob Jacobsen wrote: > Because of this and similar problems, JMRI does all it's serial IO > using +only+ byte values. It's a but of a pain, as Java wants to go > to char and int types a little too aggressively, but it does solve > the "uncontrolled conversions" problems. Anytime that you are reading bytes of data that is not printable, unicode text, in Java, you really need to stay away from the Readers. Use input stream only, or you will see unicode valued byte groups converted to unicode "char" values. Gregg Wonderly From joachim at buechse.de Mon Mar 5 04:23:48 2007 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 5 Mar 2007 12:23:48 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> Message-ID: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> The behaviour is exactly what you asked for in you code. is = new BufferedReader(new InputStreamReader(port.getInputStream())); Readers return Text (ie unicode chars) not bytes. You instantiate the InputStreamReader without saying which charset you want, which means "platform default". As this is on Windows, it will convert Windows characters to equivalent unicode characters. If you want to read bytes, read bytes not Text. Reading bytes is done with InputStream and BufferedInputStream. BTW: The InputStream and Reader methods that read arrays are not guarenteed to fill up the array. You always have to check what you really got, and advance your index accordingly. A typical "read up to 32k" method looks like this: InputStream is= ... // -- determine the max buffer size int len= is.available(); if (len == 0) { len= 32 * 1024; } // -- read all available data byte[] buffer= new byte[len]; int pos= 0; int read; do { read= is.read(buffer, pos, buffer.length - pos); pos= pos + read; } while (read != -1 && pos < buffer.length); Best regards, Joachim --- Joachim B?chse Phone: +41 44 500 2604 Buechse Consulting Hadlaubsteig 2 CH-8006 Z?rich On 03.03.2007, at 23:10, Keith wrote: > Bob said ..... > >> Java's "char" type is Unicode. I think what you're seeing is a bug >> in the byte -> Unicode translation. > > Bob -- I think you hit the nail on the head. > > I was just coming to the same realization here. I knew that > something funny > was going on because the same bytes always got "corrupted." > > I'm pretty sure its in the InputStreamReader() functionality where the > conversion junk is happening. > > Bytes with values 0 -> 127 were left unharmed, as were 160 -> 255. > > I don't know if simply changing the cast is going to work. Since the > conversion is happening upstream (pun intended), I don't think my > cast is > doing this. Also I think the compiler forced me to use the cast. > > I'm still playing around, and I'll report back once I nail it down. > > Thanks!! > > Keith > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Mon Mar 5 07:25:46 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 05 Mar 2007 08:25:46 -0600 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> Message-ID: <45EC286A.8060608@cox.net> Joachim Buechse wrote: > BTW: The InputStream and Reader methods that read arrays are not > guarenteed to fill up the array. You always have to check what you > really got, and advance your index accordingly. A typical "read up to > 32k" method looks like this: > > InputStream is= ... > // -- determine the max buffer size > int len= is.available(); > if (len == 0) { > len= 32 * 1024; > } > // -- read all available data > byte[] buffer= new byte[len]; > int pos= 0; > int read; > do { > read= is.read(buffer, pos, buffer.length - pos); > pos= pos + read; > } while (read != -1 && pos < buffer.length); > My preferred structure is. byte arr[ len ]; int cnt; int off = 0; while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { off += cnt; } This keeps you from adding -1 to pos when the read returns -1. It also skips out when the read is 0 bytes which, is not a described EOF in InputStream java docs, but is a condition I want to be aware of. Gregg Wonderly From joachim at buechse.de Tue Mar 6 02:52:58 2007 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 6 Mar 2007 10:52:58 +0100 Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: <45EC286A.8060608@cox.net> References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: The code I copied was from a file resource reader, it shouldn't really be applied to networking/external IO code. Mea culpa. However aborting when you get 0 from read is not always what you want either (you kind of indicated that already). Some unix java implementations will return 0 if the kernel read was aborted with EINTER, which is rarely the point where you want to abort your read - at least not without further checks. A "complete" solution always depends on the events you need to handle and the time the total read could take in reality. In some cases it's worth checking Thread.isInterrupted() in the loop, some code re-loops on 0 but only a limited number of times, some check a total timeout limit, etc... Best regards, Joachim On 05.03.2007, at 15:25, Gregg Wonderly wrote: > My preferred structure is. > > byte arr[ len ]; > int cnt; > int off = 0; > while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { > off += cnt; > } > > This keeps you from adding -1 to pos when the read returns -1. It > also skips > out when the read is 0 bytes which, is not a described EOF in > InputStream java > docs, but is a condition I want to be aware of. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Mar 6 14:47:44 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 Mar 2007 14:47:44 -0700 (MST) Subject: [Rxtx] is.read() only returning 3968 bytes In-Reply-To: References: <000c01c75d5b$d646a6b0$6600a8c0@jbh757ktruws7g> <000901c75db0$a9f8a360$6600a8c0@jbh757ktruws7g> <000c01c75de0$b6d09950$6600a8c0@jbh757ktruws7g> <888402C5-078C-4EED-A207-047BDE6488E3@buechse.de> <45EC286A.8060608@cox.net> Message-ID: Just FYI, rxtx will usually not break out on EINTER. The code in the native library usually does something close to this: do { read(...) } while ( !done && errno==EINTR ); Obviously there is a little more involved but it will retry on EINTER if not done. On Tue, 6 Mar 2007, Joachim Buechse wrote: > The code I copied was from a file resource reader, it shouldn't > really be applied to networking/external IO code. Mea culpa. > > However aborting when you get 0 from read is not always what you want > either (you kind of indicated that already). Some unix java > implementations will return 0 if the kernel read was aborted with > EINTER, which is rarely the point where you want to abort your read - > at least not without further checks. A "complete" solution always > depends on the events you need to handle and the time the total read > could take in reality. In some cases it's worth checking > Thread.isInterrupted() in the loop, some code re-loops on 0 but only > a limited number of times, some check a total timeout limit, etc... > > Best regards, > Joachim > > On 05.03.2007, at 15:25, Gregg Wonderly wrote: >> My preferred structure is. >> >> byte arr[ len ]; >> int cnt; >> int off = 0; >> while ( ( cnt = read( arr, off, arr.length - off ) > 0 ) { >> off += cnt; >> } >> >> This keeps you from adding -1 to pos when the read returns -1. It >> also skips >> out when the read is 0 bytes which, is not a described EOF in >> InputStream java >> docs, but is a condition I want to be aware of. >> >> Gregg Wonderly >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 gjhanna at gmail.com Thu Mar 8 13:42:52 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Fri, 9 Mar 2007 09:42:52 +1300 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? Message-ID: I've just struck an issue using rxtx in a multi-threaded environment: If I have 3 threads trying to open *the same* comm-port I get a deadlock in CommPortIdentifier.open If I have just 2, it works fine - I get a PortInUseException which is nice and I can handle it. The 3 thread->deadlock thing is causing me issues. (Sample code below). This is from the java thread-dump Found one Java-level deadlock: ============================= "Thread-2": waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object ), which is held by "Thread-1" "Thread-1": waiting to lock monitor 0x0003e9cc (object 0x2450e108, a gnu.io.CommPortIdentifier), which is held by "Thread-2" Java stack information for the threads listed above: =================================================== "Thread-2": at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:329) - waiting to lock <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) "Thread-1": at java.lang.Object.wait(Native Method) - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) - locked <0x240b08e8> (a java.lang.Object) - locked <0x2450e108> (a gnu.io.CommPortIdentifier) at OpenThread.run(RXTXLockTest.java:42) (Apart from this, rxtx is working fantastically for us). I'm thinking I'll have to implement some sort of locking mechanism that *doesn't* use java synchronization to prevent this situation. (Which doesn't sound like a good idea to me). Any ideas? Thanks, Greg Hanna ============= RXTXLockTest.java ======================================== import gnu.io.CommPort; import gnu.io.CommPortIdentifier; /** * @author Greg Hanna * Minimal code to create a deadlock with rxtx in multithreaded open */ public class RXTXLockTest { public static void main(String[] args) { try { CommPortIdentifier cpiCom1 = CommPortIdentifier.getPortIdentifier ("COM14"); OpenThread t1 = new OpenThread (" one ", cpiCom1); OpenThread t2 = new OpenThread (" two ", cpiCom1); OpenThread t3 = new OpenThread (" 003 ", cpiCom1); t1.start(); t2.start(); t3.start(); // comment this out and it runs with (expected) PortInUseException } catch (Exception e) { e.printStackTrace(); } } } class OpenThread extends Thread { String name; CommPortIdentifier cpi; CommPort cp; public OpenThread (String name, CommPortIdentifier cpi) { this.name = name; this.cpi = cpi; System.out.println (System.currentTimeMillis() + name + " thread created"); } public void run () { try { System.out.println (System.currentTimeMillis() + name + " opening"); cp = cpi.open(name, 2000); System.out.println (System.currentTimeMillis() + name + " opened - sleeping"); sleep (2000); // do the serial comms with the device. System.out.println (System.currentTimeMillis() + name + " slept - closing"); cp.close(); System.out.println (System.currentTimeMillis() + name + " closed - exiting"); } catch (Exception e) { System.out.println ("Error in thread: " + name ); e.printStackTrace(); } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070308/d9a163c5/attachment-0007.html From eu259473 at tele2.it Fri Mar 9 02:46:20 2007 From: eu259473 at tele2.it ("Giuseppe Marchese" ) Date: Fri, 09 Mar 2007 10:46:20 +0100 Subject: [Rxtx] rxtx: tru64 unix make fails Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070309/3b654523/attachment-0007.html From lyon at docjava.com Fri Mar 9 03:58:32 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 Mar 2007 05:58:32 -0500 Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi All, The deadlock issue is one that I have been thinking about for some time now. It seems to me that we need a resource manager that enables assignment to a known process. The one thing that seems important about serial ports is that two applications should not use the same serial port at the same time. When this happens, it throws an exception. OK. The exception is a response to a lock condition that arises from an unavailable resource. An abstract implementation (not born of native methods) might assign a serial port to an application, until the application releases it (or is forced to release it by some kill mechanism). Some resources (like a registry) can be reused. But others, like the serial port, cannot. In the case of the serial port, we would like, I think, to have the flyweight design pattern without sharing and with object assignment tracking. A means of breaking deadlock (like a leasing mechanism) seems very useful, to me. My guess is that we can serialize the state of the Parametric Singleton Pattern (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) into the Preferences of the System. Preferences.systemRoot() might help with that. When a resource is checked out, the lease time and owner are listed. A thread that does this can be killed, but applications outside of Java are problematic. There is a compelling problem here. It is not just serial ports. Sound cards, cameras, microphones, files, tape drives, etc. All are consumed resources that are assigned to an application (or user) and deprive other applications, or users, from use. What, if anything, should we do? At present we throw PortInUseExceptions. Is that it? Can we do better? OK, the port is in use. Now what? Do I have to be root to go remove lock files and kill applications? Is there a better way? Thanks! - Doug >I've just struck an issue using rxtx in a multi-threaded environment: > >If I have 3 threads trying to open *the same* >comm-port I get a deadlock in >CommPortIdentifier.open >If I have just 2, it works fine - I get a >PortInUseException which is nice and I can >handle it. > >The 3 thread->deadlock thing is causing me issues. >(Sample code below). > >This is from the java thread-dump > >Found one Java-level deadlock: >============================= >"Thread-2": > waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), > which is held by "Thread-1" >"Thread-1": > waiting to lock monitor 0x0003e9cc (object >0x2450e108, a gnu.io.CommPortIdentifier ), > which is held by "Thread-2" > >Java stack information for the threads listed above: >=================================================== >"Thread-2": > at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) > - waiting to lock <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) >"Thread-1": > at java.lang.Object.wait(Native Method) > - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) > - locked <0x240b08e8> (a java.lang.Object) > - locked <0x2450e108> (a gnu.io.CommPortIdentifier) > at OpenThread.run(RXTXLockTest.java:42) > > >(Apart from this, rxtx is working fantastically for us). > >I'm thinking I'll have to implement some sort of >locking mechanism that *doesn't* use java >synchronization to prevent this situation. >(Which doesn't sound like a good idea to me). > >Any ideas? > >Thanks, > >Greg Hanna > >============= RXTXLockTest.java ======================================== > >import gnu.io.CommPort; >import gnu.io.CommPortIdentifier; > >/** > * @author Greg Hanna > * Minimal code to create a deadlock with rxtx in multithreaded open > */ >public class RXTXLockTest { > ? > ?public static void main(String[] args) { > ?try { > ?CommPortIdentifier cpiCom1 = >CommPortIdentifier.getPortIdentifier ("COM14"); > ?OpenThread t1 = new OpenThread (" one ", cpiCom1); > ?OpenThread t2 = new OpenThread (" two ", cpiCom1); > ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); > ?t1.start(); > ?t2.start(); > ?t3.start(); // comment this out >and it runs with (expected) PortInUseException > ?} catch (Exception e) { > ?e.printStackTrace(); > ?} > ?} >} > >class OpenThread extends Thread { > ?String name; > ?CommPortIdentifier cpi; > ?CommPort cp; > ?public OpenThread (String name, CommPortIdentifier cpi) { > ? this.name = name; > ?this.cpi = cpi; > ?System.out.println >(System.currentTimeMillis() + name + " thread >created"); > ?} > ?public void run () { > ?try { > ?System.out.println >(System.currentTimeMillis() + name + " opening"); > ?cp = cpi.open(name, 2000); > ?System.out.println >(System.currentTimeMillis() + name + " opened - >sleeping"); > ?sleep (2000); // do the serial comms with the device. > ?System.out.println >(System.currentTimeMillis() + name + " slept - >closing"); > ?cp.close(); > ?System.out.println >(System.currentTimeMillis() + name + " closed - >exiting"); > ?} catch (Exception e) { > System.out.println ("Error in thread: " + name ); > ?e.printStackTrace(); > ?} > ?} >} > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Mar 9 06:37:45 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 Mar 2007 06:37:45 -0700 (MST) Subject: [Rxtx] rxtx: tru64 unix make fails In-Reply-To: References: Message-ID: On Fri, 9 Mar 2007, "Giuseppe Marchese" wrote: > Sorry for delay. > ? > This is log for ./configure and make > error. > ? > thanks for attention > ? > Make: '%.java,$(TOP)/$(CLASSDEST)/%.class,$(wildcard $(SPATH)/*.java)': extra chars.? > Stop. > Hi Giuseppe You need to use GNU make with the Makefile. I suspect the tru64 make is not happy with those rules. > configure: exit 0 Looks like configure is fairly happy. From tjarvi at qbang.org Sat Mar 10 07:43:51 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 07:43:51 -0700 (MST) Subject: [Rxtx] Deadlock in CommPortIdentifier.open with 3 threads ? In-Reply-To: References: Message-ID: Hi Doug I have very little time to look into this further but what we could do is open up an rxtx 3 devel branch in which a proof of concept could be worked on. It could be the proof of concept for a JSR others including Sun could look at/work on or parts of it could be recycled in a JSR. I'm working very hard on rxtx right now but it does not show. I'm looking at win64, mac intel/ppc, usb bluetooth and usb serial dongles. Some are going to be more tested than others but they are all on the plate. I'll be pushing all the fixes upstream when they are done. So I'm very busy in 2.1 but we could open a new branch. On Fri, 9 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > The deadlock issue is one that I have been thinking about > for some time now. > It seems to me that we need a resource manager that enables assignment > to a known process. > > The one thing that seems important about serial > ports is that two applications should not use the > same serial port at the same time. When this > happens, it throws an exception. > OK. > > The exception is a response to a lock condition that > arises from an unavailable resource. > > An abstract implementation (not born of native methods) might > assign a serial port to an application, until the > application releases it (or is forced to release > it by some kill mechanism). > > Some resources (like a registry) can be reused. > But others, like the serial port, > cannot. > > In the case of the serial port, we would like, I think, to > have the flyweight design pattern > without sharing and with object assignment tracking. > A means of breaking deadlock (like a leasing > mechanism) seems very useful, to me. > > My guess is that we can serialize the state of the Parametric Singleton Pattern > (see: http://show.docjava.com:8086/pub/document/jot/v6n3.pdf) > into the Preferences of the System. Preferences.systemRoot() might help > with that. When a resource is checked out, the lease time and owner are > listed. A thread that does this can be killed, but applications outside of Java > are problematic. > > There is a compelling problem here. It is not just serial ports. > Sound cards, cameras, microphones, files, tape drives, etc. All are consumed > resources that are assigned to an application (or > user) and deprive other applications, > or users, from use. > > What, if anything, should we do? At present we throw PortInUseExceptions. > Is that it? > Can we do better? > OK, the port is in use. Now what? > Do I have to be root to go remove lock files and kill applications? > Is there a better way? > > Thanks! > - Doug > >> I've just struck an issue using rxtx in a multi-threaded environment: >> >> If I have 3 threads trying to open *the same* >> comm-port I get a deadlock in >> CommPortIdentifier.open >> If I have just 2, it works fine - I get a >> PortInUseException which is nice and I can >> handle it. >> >> The 3 thread->deadlock thing is causing me issues. >> (Sample code below). >> >> This is from the java thread-dump >> >> Found one Java-level deadlock: >> ============================= >> "Thread-2": >> waiting to lock monitor 0x0003e9ec (object 0x240b08e8, a java.lang.Object), >> which is held by "Thread-1" >> "Thread-1": >> waiting to lock monitor 0x0003e9cc (object >> 0x2450e108, a gnu.io.CommPortIdentifier ), >> which is held by "Thread-2" >> >> Java stack information for the threads listed above: >> =================================================== >> "Thread-2": >> at gnu.io.CommPortIdentifier.open (CommPortIdentifier.java:329) >> - waiting to lock <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> "Thread-1": >> at java.lang.Object.wait(Native Method) >> - waiting on <0x2450e108> (a gnu.io.CommPortIdentifier) >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:332) >> - locked <0x240b08e8> (a java.lang.Object) >> - locked <0x2450e108> (a gnu.io.CommPortIdentifier) >> at OpenThread.run(RXTXLockTest.java:42) >> >> >> (Apart from this, rxtx is working fantastically for us). >> >> I'm thinking I'll have to implement some sort of >> locking mechanism that *doesn't* use java >> synchronization to prevent this situation. >> (Which doesn't sound like a good idea to me). >> >> Any ideas? >> >> Thanks, >> >> Greg Hanna >> >> ============= RXTXLockTest.java ======================================== >> >> import gnu.io.CommPort; >> import gnu.io.CommPortIdentifier; >> >> /** >> * @author Greg Hanna >> * Minimal code to create a deadlock with rxtx in multithreaded open >> */ >> public class RXTXLockTest { >> ? >> ?public static void main(String[] args) { >> ?try { >> ?CommPortIdentifier cpiCom1 = >> CommPortIdentifier.getPortIdentifier ("COM14"); >> ?OpenThread t1 = new OpenThread (" one ", cpiCom1); >> ?OpenThread t2 = new OpenThread (" two ", cpiCom1); >> ?OpenThread t3 = new OpenThread (" 003 ", cpiCom1); >> ?t1.start(); >> ?t2.start(); >> ?t3.start(); // comment this out >> and it runs with (expected) PortInUseException >> ?} catch (Exception e) { >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> class OpenThread extends Thread { >> ?String name; >> ?CommPortIdentifier cpi; >> ?CommPort cp; >> ?public OpenThread (String name, CommPortIdentifier cpi) { >> ? this.name = name; >> ?this.cpi = cpi; >> ?System.out.println >> (System.currentTimeMillis() + name + " thread >> created"); >> ?} >> ?public void run () { >> ?try { >> ?System.out.println >> (System.currentTimeMillis() + name + " opening"); >> ?cp = cpi.open(name, 2000); >> ?System.out.println >> (System.currentTimeMillis() + name + " opened - >> sleeping"); >> ?sleep (2000); // do the serial comms with the device. >> ?System.out.println >> (System.currentTimeMillis() + name + " slept - >> closing"); >> ?cp.close(); >> ?System.out.println >> (System.currentTimeMillis() + name + " closed - >> exiting"); >> ?} catch (Exception e) { >> System.out.println ("Error in thread: " + name ); >> ?e.printStackTrace(); >> ?} >> ?} >> } >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 mm at UDel.Edu Sat Mar 10 14:48:32 2007 From: mm at UDel.Edu (Mike Markowski) Date: Sat, 10 Mar 2007 16:48:32 -0500 Subject: [Rxtx] rxtx and Sun's comm api Message-ID: <45F327B0.2060004@udel.edu> Hi all, I joined the list a few days ago and apologize for what is likely a frequently asked question, though I haven't yet found it anywhere. I learned about rxtx.org through the readme on Sun's version 2 of their comms api. They give recommendations in that readme regarding how a better comms api should be written. Is this the aim of rxtx.org? I wrote an app on my linux box using the Sun comms api (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the fact that only linux and Solaris are supported. So I'm glad to find rxtx.org and am just reading up on how make the conversion so Windows users will be able to run the program as well. At the same time I'm just curious if rxtx.org and Sun are both heading in the same direction. Thanks for any background or historical info. Feel free to point me to any www pages if my googling has just completely missed the target! Thanks again, Mike From tjarvi at qbang.org Sat Mar 10 15:35:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 Mar 2007 15:35:25 -0700 (MST) Subject: [Rxtx] rxtx and Sun's comm api In-Reply-To: <45F327B0.2060004@udel.edu> References: <45F327B0.2060004@udel.edu> Message-ID: On Sat, 10 Mar 2007, Mike Markowski wrote: > Hi all, > > I joined the list a few days ago and apologize for what is likely a > frequently asked question, though I haven't yet found it anywhere. I > learned about rxtx.org through the readme on Sun's version 2 of their > comms api. They give recommendations in that readme regarding how a > better comms api should be written. Is this the aim of rxtx.org? > > I wrote an app on my linux box using the Sun comms api > (http://udel.edu/~mm/ham/k2/ ) for ham radio only to discover after the > fact that only linux and Solaris are supported. So I'm glad to find > rxtx.org and am just reading up on how make the conversion so Windows > users will be able to run the program as well. At the same time I'm > just curious if rxtx.org and Sun are both heading in the same direction. > > Thanks for any background or historical info. Feel free to point me to > any www pages if my googling has just completely missed the target! > I do not have any news (good or bad) concerning RXTX and Sun working together but perhaps others here do. The main goal of RXTX is to expose POSIX termios interfaces to java users. The future support of javax.comm is questionable. We do not have resources for everything. gnu.io (RXTX 2.1) will be supported going forward and functions the same as CommAPI 2.0. If you have control of the source code you are working with, I would not advise using CommAPI 2.0 javax.comm. We do support CommAPI 2.0 javax.comm for older applications but I do not think that will last much longer for practical reasons. The download interest in CommAPI 2.0 javax.comm support is becomming negligible on this end. There has been discussion of a JSR effort but I do not know of any status change since it was mentioned. One problem with a JSR is that even a light weight process is going to be difficult for RXTX at this time. Maybe that will change in the future but then again it may not. For now, we are just going forward 'as is' in rxtx 2.1 with package gnu.io while trying as a secondary effort to backport the changes to rxtx 2.0 for javax.comm support for users that do not have a choice. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Mar 11 07:19:40 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 11 Mar 2007 08:19:40 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: Hi All, I have been a proponent of a JSR that makes use of RXTX. I have executed the proper agreements with Sun. At this point we are in the: Early Draft Review of Draft Specifications Stage. The best thing to do is to enter the quiet period and create a specification. The question of exactly how we, as a group, want to approach this problem, remains open. Typically, we should have both a specification and a reference implementation. Thus, it would be to our best advantage to have a nice, stable, cross platform RXTX distro that adheres to the groups specification. Now, from a specification standpoint, my personal view on the matter is that we create a series of interfaces, with nice documentation (or at least javadoc). Is this a good idea? Should we have a pure interface specification for the communication API? There are several issues, in my mind, which still weigh on us. Hot-pluggable dongles, long discovery process on pop-up ports, lack of uniformity on device names, lack of uniformity on locking, a precise understanding of how the SerialPortResourceManager works (or even if we should have one). The more questions we answer in our reference implementation, the better our specification will get. RXTX is a good working prototype, but, I don't know if that is what we want to use for a specification. Here is what I have for a CommPortInterface: */ public interface CommPortInterface { /** * @return a string representation of this port. */ String toString(); /** * Gets the name of the communications port. This name should correspond to * something the user can identify, like the label on the hardware. * @return name of the port */ String getName(); /** * @return an input stream that can be used to read data from the * communications port. If the port doesn't support reading data, this * method returns null. *

* The blocking behaviour of this input stream depends on the threshold * and timeout values, as shown below for a read buffer size of n * bytes: * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ThresholdTimeoutBlocking behaviour
StateValueStateValue
disableddisabledblock until data is available
enabledm bytesdisabledblock until min(m, n) bytes are available
disabledenabledt msblock for t ms or until data is available
enabledm bytesenabledt msblock for t ms or until min(m, n) bytes are * available
* @throws java.io.IOException */ InputStream getInputStream() throws IOException; /** * @return an output stream that can be used to send data to the * communications port. If the port doesn't support sending data, this * method returns null. * @throws java.io.IOException */ OutputStream getOutputStream() throws IOException; /** * Closes this communications port. * All PortOwnershipListeners will be? * notified of this change of ownership. Further method calls on this? * object will throw IllegalStateException. Further calls on the? * associated InputStream or OutputStream will throw IOException. *

* Close does not block. Undelivered data is discarded. Blocked read and? * write operations are aborted if the underlying operating systems? * supports an IO abort mechanism. To await the delivery of undelivered? * data call OutputStream.flush() or OutputStream.close() before calling? * Port.close(). */ void close(); /** * Enables receive threshold. * When the specified threshold number of bytes are retrieved, read will * return immediately. * * @param thresh the number of bytes in the input buffer * @throws gnu.io.UnsupportedCommOperationException * if receive threshold is * not supported by the driver * @see #disableReceiveThreshold */ void enableReceiveThreshold(int thresh) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive threshold. * * @see #enableReceiveThreshold */ void disableReceiveThreshold(); /** * @return true if receive threshold is enabled. * * @see #enableReceiveThreshold */ boolean isReceiveThresholdEnabled(); /** * @return the receive threshold value. If receive threshold is diabled * or not supported, this value is meaningless. * * @see #enableReceiveThreshold */ int getReceiveThreshold(); /** * Enables receive timeout. * When the specified number of milliseconds have elapsed, read will * return immediately. * * @param rcvTimeout the number of milliseconds to block for * @throws gnu.io.UnsupportedCommOperationException * if receive timeout is * not supported by the driver * @see #disableReceiveTimeout */ void enableReceiveTimeout(int rcvTimeout) throws gnu.io.UnsupportedCommOperationException; /** * Disables receive timeout. * * @see #enableReceiveTimeout */ void disableReceiveTimeout(); /** * @return true if receive timeout is enabled. * * @see #enableReceiveTimeout */ boolean isReceiveTimeoutEnabled(); /** * @return the receive timeout value. If receive timeout is diabled * or not supported, this value is meaningless. * * @see #enableReceiveTimeout */ int getReceiveTimeout(); /** * Enables receive framing. * The supplied byte value in the input suggests the end of the received * frame, and read returns immediately. Only the low 8 bits of the * supplied value are significant. * * @param framingByte the frame delimiter * @throws gnu.io.UnsupportedCommOperationException * if receive framing is * not supported by the driver * @see #disableReceiveFraming */ void enableReceiveFraming(int framingByte) throws UnsupportedCommOperationException; /** * Disables receive framing. * * @see #enableReceiveFraming */ void disableReceiveFraming(); /** * @return true if receive framing is enabled. * * @see #enableReceiveFraming */ boolean isReceiveFramingEnabled(); /** * @return true if receive framing byte. If receive framing is diabled * or not supported, this value is meaningless. * * @see #enableReceiveFraming */ int getReceiveFramingByte(); /** * Sets the input buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setInputBufferSize(int size); /** * @return the input buffer size. * The driver may choose not to report correct values. */ int getInputBufferSize(); /** * Sets the output buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setOutputBufferSize(int size); /** * @return the output buffer size. * The driver may choose not to report correct values. */ int getOutputBufferSize(); } What do you think of that? Note the wishy washy nature of the spec: The driver may choose to ignore this method. Is that good enough for us? Thanks! - Doug From ra85551 at gmail.com Sun Mar 11 08:44:45 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Sun, 11 Mar 2007 17:44:45 +0300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hello, world! I am writing application that communicates with modem via AT commands. My OS is Linux Kubuntu Feisty Herd, to ensure that my application will run properly under Windows XP I installed VMWare server. When I tried to send AT command and evaluate modem answer under WinXP @ VMWare server, I actually didn't receive anything. I think that VM settings are right, because I do can communicate with modem by using standard HyperTerminall as well as I can do on native Windows. So, why RXTX doesn't work under VM, but works under Linux and pure Windows XP (i tested it there) well? The send/receive method code follows. private String sendATCommand(String command, final String waitFor, final boolean isRegex, boolean isAddCRLF, long timeout) throws BeaconConnectException { final long POLL_PERIOD = 100; final int BUFFER_SIZE = 512; final byte[] buffer = new byte[BUFFER_SIZE]; final InputStream serialInput; final OutputStream serialOutput; try { serialInput = serialPort.getInputStream(); if (command != null) { serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } } catch (IOException e) { throw new MyException("serial I/O error"); } TimerTask task = new TimerTask() { int offset = 0; int bytesRead; public synchronized void run() { try { if (serialInput.available() > 0) { bytesRead = serialInput.read(buffer, offset, BUFFER_SIZE - offset); } else { return; } } catch (IOException e) { // do nothing - maybe next time we'll read something } offset += bytesRead; if (waitFor != null) { String temporary = new String(buffer, 0, offset).trim(); if (isRegex && temporary.matches(waitFor) || temporary.contains(waitFor)) { cancel(); notify(); } } } }; Timer timer = new Timer(); timer.schedule(task, POLL_PERIOD, POLL_PERIOD); synchronized (task) { try { task.wait(timeout); task.cancel(); } catch (InterruptedException e) { } } //Cut off leading and trailing CRs, LFs and zeroes String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); System.out.println(response); return response; } -- Pavel Parkhomenko From tjarvi at qbang.org Sun Mar 11 11:48:22 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:48:22 -0600 (MDT) Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: On Sun, 11 Mar 2007, Pavel Parkhomenko wrote: > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. > > private String sendATCommand(String command, final String waitFor, > final boolean isRegex, boolean isAddCRLF, long timeout) > throws BeaconConnectException > { > final long POLL_PERIOD = 100; > final int BUFFER_SIZE = 512; > final byte[] buffer = new byte[BUFFER_SIZE]; > final InputStream serialInput; > final OutputStream serialOutput; > try > { > serialInput = serialPort.getInputStream(); > if (command != null) > { > serialOutput = serialPort.getOutputStream(); > if (isAddCRLF) > { > command += "\r\n"; > } > System.out.println(command); > serialOutput.write(command.getBytes()); > } > } > catch (IOException e) > { > throw new MyException("serial I/O error"); > } > > TimerTask task = new TimerTask() > { > int offset = 0; > int bytesRead; > public synchronized void run() > { > try > { > if (serialInput.available() > 0) > { > bytesRead = serialInput.read(buffer, offset, > BUFFER_SIZE - offset); > } > else > { > return; > } > } > catch (IOException e) > { > // do nothing - maybe next time we'll read something > } > offset += bytesRead; > if (waitFor != null) > { > String temporary = new String(buffer, 0, offset).trim(); > if (isRegex && temporary.matches(waitFor) || > temporary.contains(waitFor)) > { > cancel(); > notify(); > } > } > } > }; > > Timer timer = new Timer(); > timer.schedule(task, POLL_PERIOD, POLL_PERIOD); > synchronized (task) { > try > { > task.wait(timeout); > task.cancel(); > } > catch (InterruptedException e) > { > } > } > //Cut off leading and trailing CRs, LFs and zeroes > String response = (new String(buffer, 0, BUFFER_SIZE)).trim(); > System.out.println(response); > return response; > } > > > Hi Pavel VMWare should not be a problem. I've used it in the past - though not with a modem. Make sure nothing else is using the modem. Then look in the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an example that should work. Note that modems could care less what OS is on top. If you are trying to match new lines to the OS and sending it to the mode for AT commands, thats probably a mistake. Also it would not hurt to print out the individual bytes that you are sending to make sure they did not get mangled along the path. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 11:55:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 11:55:48 -0600 (MDT) Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: On Sun, 11 Mar 2007, Dr. Douglas Lyon wrote: > Hi All, > I have been a proponent of a JSR that makes > use of RXTX. I have executed the proper agreements with Sun. > > At this point we are in the: > Early Draft Review of Draft Specifications Stage. > > The best thing to do is to enter the quiet period and create > a specification. The question of exactly how we, as a group, > want to approach this problem, remains open. > > Typically, we should have both a specification and a reference > implementation. Thus, it would be to our best advantage to have > a nice, stable, cross platform RXTX distro that adheres to the > groups specification. > > Now, from a specification standpoint, my personal view on the matter is > that we create a series of interfaces, with nice documentation (or at least > javadoc). > > Is this a good idea? Should we have a pure interface specification for > the communication API? > > There are several issues, in my mind, which still weigh on us. > Hot-pluggable dongles, long discovery process on pop-up ports, > lack of uniformity on device names, lack of uniformity on locking, > a precise understanding of how the SerialPortResourceManager > works (or even if we should have one). > > The more questions we answer in our reference implementation, the > better our specification will get. RXTX is a good working prototype, > but, I don't know if that is what we want to use for a specification. > > Here is what I have for a CommPortInterface: > */ > public interface CommPortInterface { Hi Doug, I can start going through the method interfaces later this week and giving feedback. I would suggest that the JSR should not be too generic in nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel drivers that intend to look like EIA232 ports at the kernel driver level. some ideas: EIA232PortInterface TermiosInterface SerialPortInterface Something that differentiates this from thing like USB, I2C, ... which should not have to deal with legacy serial claiming to be the comm api. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Mar 11 12:52:19 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 11 Mar 2007 12:52:19 -0600 (MDT) Subject: [Rxtx] RXTX consolidated license proposal (2/2) In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848AB94AA@ism-mail03.corp.ad.wrs.com> Message-ID: No news is good news with these posts. I'll start the process of pinging legal a week from Monday on my end if nobody has objections to the proposal. I just want to make sure everyone has time to raise objections. Obviously, anyone can fork from a previous version if they don't like the new license. I suspect we can avoid that though. On Sun, 4 Mar 2007, Trent Jarvi wrote: > > For those that are wondering what is going on here, this > next bit is the meat of the changes. We agreed a long time > ago to put this disclaimer in. We did a so so job. It was > in rxtx 2.0, not well written, ... So some groups using > rxtx that would like to ship rxtx so users don't need to > download, install, go to the mail-list to find why it failed, > ... Then their legal teams tell them section 5 paragraph 2 > is a show stopper. > > That was never the intent. > > > Now going through what remains... > >> and might need a (TM) suffix to make Sun happy. > > Added disclaimer at the ended 'all trademarks belong...' > >> * Line #15ff - static vs. dynamic linking - you did >> not transcribe the text from the "controlled >> interface exception" when writing this text - and >> this was good so, because these terms originally >> refer to the GPL rather than the LGPL. I think though, >> that these 4 lines are the most important ones and >> should thus be really really clear. I hope that I >> meet your original intent with the following >> suggestions: >> 1.) Instead of "A program.." it would be better to >> say "An exectuable.." in order to be closer to >> the LGPL text. > > OK. As you can see I was trying to adjust GNU text there > for the LGPL. > >> 2.) It would be better to say .. "by being dynamically >> linked with it" to clearly indicate that dynamic >> linking is meant. The matter of compilation is >> already covered by the LGPL so mentioning it again >> just leads to confusion. > > used dynamically linked terminology. > >> 3.) It would be better to say .. "is considered a >> work that uses the library in contrast to section >> 5 of the LGPL, so the terms of the LGPL do not >> apply to the resulting executable". > > I tried to address this more upfront with an intent statement. > Let me know if you have problems with it. I also tried to > make it a little more clear what was derived from the GNU > solution by moving the link location closer to GNU's suggestion. > >> >> Note that LGPL section 5 says: ..."is called a >> "work that uses the Library". Such a work, in isolation, >> is not a derivative work of the Library, and therefore >> falls outside the scope of this License." >> The next paragraph of the LGPL is exactly the problematic >> one that I hope is clarified by the exception terms you >> give. >> > > Thats the intent. Here is the combined fixes. Note that only the > material in /*-- --*/ is being touched. The new GPL license is > there but unmodified. > > > ------------------------ begin proposed new license ------------------- > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Lesser General Public > | License as published by the Free Software Foundation; either > | version 2.1 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Lesser General Public License for more details. > | > | An executable that contains no derivative of any portion of RXTX, but > | is designed to work with RXTX by being dynamically linked with it, > | is considered a "work that uses the Library" subject to the terms and > | conditions of the GNU Lesser General Public License. > | > | The following has been added to the RXTX License to remove > | any confusion about linking to RXTX. We want to allow in part what > | section 5, paragraph 2 of the LGPL does not permit in the special > | case of linking over a controlled interface. The intent is to add a > | Java Specification Request or standards body defined interface in the > | future as another exception but one is not currently available. > | > | http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface > | > | As a special exception, the copyright holders of RXTX give you > | permission to link RXTX with independent modules that communicate with > | RXTX solely through the Sun Microsytems CommAPI interface version 2, > | regardless of the license terms of these independent modules, and to copy > | and distribute the resulting combined work under terms of your choice, > | provided that every copy of the combined work is accompanied by a complete > | copy of the source code of RXTX (the version of RXTX used to produce the > | combined work), being distributed under the terms of the GNU Lesser General > | Public License plus this exception. An independent module is a > | module which is not derived from or based on RXTX. > | > | Note that people who make modified versions of RXTX are not obligated > | to grant this special exception for their modified versions; it is > | their choice whether to do so. The GNU Lesser General Public License > | gives permission to release a modified version without this exception; this > | exception also makes it possible to release a modified version which > | carries forward this exception. > | > | You should have received a copy of the GNU Lesser General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > | All trademarks belong to their respective owners. > --------------------------------------------------------------------------*/ > > The original GNU Lesser General Public License Follows. > > > GNU LESSER GENERAL PUBLIC LICENSE > Version 2.1, February 1999 > > Copyright (C) 1991, 1999 Free Software Foundation, Inc. > 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > Everyone is permitted to copy and distribute verbatim copies > of this license document, but changing it is not allowed. > > [This is the first released version of the Lesser GPL. It also counts > as the successor of the GNU Library Public License, version 2, hence > the version number 2.1.] > > Preamble > > The licenses for most software are designed to take away your > freedom to share and change it. By contrast, the GNU General Public > Licenses are intended to guarantee your freedom to share and change > free software--to make sure the software is free for all its users. > > This license, the Lesser General Public License, applies to some > specially designated software packages--typically libraries--of the > Free Software Foundation and other authors who decide to use it. You > can use it too, but we suggest you first think carefully about whether > this license or the ordinary General Public License is the better > strategy to use in any particular case, based on the explanations below. > > When we speak of free software, we are referring to freedom of use, > not price. Our General Public Licenses are designed to make sure that > you have the freedom to distribute copies of free software (and charge > for this service if you wish); that you receive source code or can get > it if you want it; that you can change the software and use pieces of > it in new free programs; and that you are informed that you can do > these things. > > To protect your rights, we need to make restrictions that forbid > distributors to deny you these rights or to ask you to surrender these > rights. These restrictions translate to certain responsibilities for > you if you distribute copies of the library or if you modify it. > > For example, if you distribute copies of the library, whether gratis > or for a fee, you must give the recipients all the rights that we gave > you. You must make sure that they, too, receive or can get the source > code. If you link other code with the library, you must provide > complete object files to the recipients, so that they can relink them > with the library after making changes to the library and recompiling > it. And you must show them these terms so they know their rights. > > We protect your rights with a two-step method: (1) we copyright the > library, and (2) we offer you this license, which gives you legal > permission to copy, distribute and/or modify the library. > > To protect each distributor, we want to make it very clear that > there is no warranty for the free library. Also, if the library is > modified by someone else and passed on, the recipients should know > that what they have is not the original version, so that the original > author's reputation will not be affected by problems that might be > introduced by others. > > Finally, software patents pose a constant threat to the existence of > any free program. We wish to make sure that a company cannot > effectively restrict the users of a free program by obtaining a > restrictive license from a patent holder. Therefore, we insist that > any patent license obtained for a version of the library must be > consistent with the full freedom of use specified in this license. > > Most GNU software, including some libraries, is covered by the > ordinary GNU General Public License. This license, the GNU Lesser > General Public License, applies to certain designated libraries, and > is quite different from the ordinary General Public License. We use > this license for certain libraries in order to permit linking those > libraries into non-free programs. > > When a program is linked with a library, whether statically or using > a shared library, the combination of the two is legally speaking a > combined work, a derivative of the original library. The ordinary > General Public License therefore permits such linking only if the > entire combination fits its criteria of freedom. The Lesser General > Public License permits more lax criteria for linking other code with > the library. > > We call this license the "Lesser" General Public License because it > does Less to protect the user's freedom than the ordinary General > Public License. It also provides other free software developers Less > of an advantage over competing non-free programs. These disadvantages > are the reason we use the ordinary General Public License for many > libraries. However, the Lesser license provides advantages in certain > special circumstances. > > For example, on rare occasions, there may be a special need to > encourage the widest possible use of a certain library, so that it becomes > a de-facto standard. To achieve this, non-free programs must be > allowed to use the library. A more frequent case is that a free > library does the same job as widely used non-free libraries. In this > case, there is little to gain by limiting the free library to free > software only, so we use the Lesser General Public License. > > In other cases, permission to use a particular library in non-free > programs enables a greater number of people to use a large body of > free software. For example, permission to use the GNU C Library in > non-free programs enables many more people to use the whole GNU > operating system, as well as its variant, the GNU/Linux operating > system. > > Although the Lesser General Public License is Less protective of the > users' freedom, it does ensure that the user of a program that is > linked with the Library has the freedom and the wherewithal to run > that program using a modified version of the Library. > > The precise terms and conditions for copying, distribution and > modification follow. Pay close attention to the difference between a > "work based on the library" and a "work that uses the library". The > former contains code derived from the library, whereas the latter must > be combined with the library in order to run. > > GNU LESSER GENERAL PUBLIC LICENSE > TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION > > 0. This License Agreement applies to any software library or other > program which contains a notice placed by the copyright holder or > other authorized party saying it may be distributed under the terms of > this Lesser General Public License (also called "this License"). > Each licensee is addressed as "you". > > A "library" means a collection of software functions and/or data > prepared so as to be conveniently linked with application programs > (which use some of those functions and data) to form executables. > > The "Library", below, refers to any such software library or work > which has been distributed under these terms. A "work based on the > Library" means either the Library or any derivative work under > copyright law: that is to say, a work containing the Library or a > portion of it, either verbatim or with modifications and/or translated > straightforwardly into another language. (Hereinafter, translation is > included without limitation in the term "modification".) > > "Source code" for a work means the preferred form of the work for > making modifications to it. For a library, complete source code means > all the source code for all modules it contains, plus any associated > interface definition files, plus the scripts used to control compilation > and installation of the library. > > Activities other than copying, distribution and modification are not > covered by this License; they are outside its scope. The act of > running a program using the Library is not restricted, and output from > such a program is covered only if its contents constitute a work based > on the Library (independent of the use of the Library in a tool for > writing it). Whether that is true depends on what the Library does > and what the program that uses the Library does. > > 1. You may copy and distribute verbatim copies of the Library's > complete source code as you receive it, in any medium, provided that > you conspicuously and appropriately publish on each copy an > appropriate copyright notice and disclaimer of warranty; keep intact > all the notices that refer to this License and to the absence of any > warranty; and distribute a copy of this License along with the > Library. > > You may charge a fee for the physical act of transferring a copy, > and you may at your option offer warranty protection in exchange for a > fee. > > 2. You may modify your copy or copies of the Library or any portion > of it, thus forming a work based on the Library, and copy and > distribute such modifications or work under the terms of Section 1 > above, provided that you also meet all of these conditions: > > a) The modified work must itself be a software library. > > b) You must cause the files modified to carry prominent notices > stating that you changed the files and the date of any change. > > c) You must cause the whole of the work to be licensed at no > charge to all third parties under the terms of this License. > > d) If a facility in the modified Library refers to a function or a > table of data to be supplied by an application program that uses > the facility, other than as an argument passed when the facility > is invoked, then you must make a good faith effort to ensure that, > in the event an application does not supply such function or > table, the facility still operates, and performs whatever part of > its purpose remains meaningful. > > (For example, a function in a library to compute square roots has > a purpose that is entirely well-defined independent of the > application. Therefore, Subsection 2d requires that any > application-supplied function or table used by this function must > be optional: if the application does not supply it, the square > root function must still compute square roots.) > > These requirements apply to the modified work as a whole. If > identifiable sections of that work are not derived from the Library, > and can be reasonably considered independent and separate works in > themselves, then this License, and its terms, do not apply to those > sections when you distribute them as separate works. But when you > distribute the same sections as part of a whole which is a work based > on the Library, the distribution of the whole must be on the terms of > this License, whose permissions for other licensees extend to the > entire whole, and thus to each and every part regardless of who wrote > it. > > Thus, it is not the intent of this section to claim rights or contest > your rights to work written entirely by you; rather, the intent is to > exercise the right to control the distribution of derivative or > collective works based on the Library. > > In addition, mere aggregation of another work not based on the Library > with the Library (or with a work based on the Library) on a volume of > a storage or distribution medium does not bring the other work under > the scope of this License. > > 3. You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. To do > this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version 2, > instead of to this License. (If a newer version than version 2 of the > ordinary GNU General Public License has appeared, then you can specify > that version instead if you wish.) Do not make any other change in > these notices. > > Once this change is made in a given copy, it is irreversible for > that copy, so the ordinary GNU General Public License applies to all > subsequent copies and derivative works made from that copy. > > This option is useful when you wish to copy part of the code of > the Library into a program that is not a library. > > 4. You may copy and distribute the Library (or a portion or > derivative of it, under Section 2) in object code or executable form > under the terms of Sections 1 and 2 above provided that you accompany > it with the complete corresponding machine-readable source code, which > must be distributed under the terms of Sections 1 and 2 above on a > medium customarily used for software interchange. > > If distribution of object code is made by offering access to copy > from a designated place, then offering equivalent access to copy the > source code from the same place satisfies the requirement to > distribute the source code, even though third parties are not > compelled to copy the source along with the object code. > > 5. A program that contains no derivative of any portion of the > Library, but is designed to work with the Library by being compiled or > linked with it, is called a "work that uses the Library". Such a > work, in isolation, is not a derivative work of the Library, and > therefore falls outside the scope of this License. > > However, linking a "work that uses the Library" with the Library > creates an executable that is a derivative of the Library (because it > contains portions of the Library), rather than a "work that uses the > library". The executable is therefore covered by this License. > Section 6 states terms for distribution of such executables. > > When a "work that uses the Library" uses material from a header file > that is part of the Library, the object code for the work may be a > derivative work of the Library even though the source code is not. > Whether this is true is especially significant if the work can be > linked without the Library, or if the work is itself a library. The > threshold for this to be true is not precisely defined by law. > > If such an object file uses only numerical parameters, data > structure layouts and accessors, and small macros and small inline > functions (ten lines or less in length), then the use of the object > file is unrestricted, regardless of whether it is legally a derivative > work. (Executables containing this object code plus portions of the > Library will still fall under Section 6.) > > Otherwise, if the work is a derivative of the Library, you may > distribute the object code for the work under the terms of Section 6. > Any executables containing that work also fall under Section 6, > whether or not they are linked directly with the Library itself. > > 6. As an exception to the Sections above, you may also combine or > link a "work that uses the Library" with the Library to produce a > work containing portions of the Library, and distribute that work > under terms of your choice, provided that the terms permit > modification of the work for the customer's own use and reverse > engineering for debugging such modifications. > > You must give prominent notice with each copy of the work that the > Library is used in it and that the Library and its use are covered by > this License. You must supply a copy of this License. If the work > during execution displays copyright notices, you must include the > copyright notice for the Library among them, as well as a reference > directing the user to the copy of this License. Also, you must do one > of these things: > > a) Accompany the work with the complete corresponding > machine-readable source code for the Library including whatever > changes were used in the work (which must be distributed under > Sections 1 and 2 above); and, if the work is an executable linked > with the Library, with the complete machine-readable "work that > uses the Library", as object code and/or source code, so that the > user can modify the Library and then relink to produce a modified > executable containing the modified Library. (It is understood > that the user who changes the contents of definitions files in the > Library will not necessarily be able to recompile the application > to use the modified definitions.) > > b) Use a suitable shared library mechanism for linking with the > Library. A suitable mechanism is one that (1) uses at run time a > copy of the library already present on the user's computer system, > rather than copying library functions into the executable, and (2) > will operate properly with a modified version of the library, if > the user installs one, as long as the modified version is > interface-compatible with the version that the work was made with. > > c) Accompany the work with a written offer, valid for at > least three years, to give the same user the materials > specified in Subsection 6a, above, for a charge no more > than the cost of performing this distribution. > > d) If distribution of the work is made by offering access to copy > from a designated place, offer equivalent access to copy the above > specified materials from the same place. > > e) Verify that the user has already received a copy of these > materials or that you have already sent this user a copy. > > For an executable, the required form of the "work that uses the > Library" must include any data and utility programs needed for > reproducing the executable from it. However, as a special exception, > the materials to be distributed need not include anything that is > normally distributed (in either source or binary form) with the major > components (compiler, kernel, and so on) of the operating system on > which the executable runs, unless that component itself accompanies > the executable. > > It may happen that this requirement contradicts the license > restrictions of other proprietary libraries that do not normally > accompany the operating system. Such a contradiction means you cannot > use both them and the Library together in an executable that you > distribute. > > 7. You may place library facilities that are a work based on the > Library side-by-side in a single library together with other library > facilities not covered by this License, and distribute such a combined > library, provided that the separate distribution of the work based on > the Library and of the other library facilities is otherwise > permitted, and provided that you do these two things: > > a) Accompany the combined library with a copy of the same work > based on the Library, uncombined with any other library > facilities. This must be distributed under the terms of the > Sections above. > > b) Give prominent notice with the combined library of the fact > that part of it is a work based on the Library, and explaining > where to find the accompanying uncombined form of the same work. > > 8. You may not copy, modify, sublicense, link with, or distribute > the Library except as expressly provided under this License. Any > attempt otherwise to copy, modify, sublicense, link with, or > distribute the Library is void, and will automatically terminate your > rights under this License. However, parties who have received copies, > or rights, from you under this License will not have their licenses > terminated so long as such parties remain in full compliance. > > 9. You are not required to accept this License, since you have not > signed it. However, nothing else grants you permission to modify or > distribute the Library or its derivative works. These actions are > prohibited by law if you do not accept this License. Therefore, by > modifying or distributing the Library (or any work based on the > Library), you indicate your acceptance of this License to do so, and > all its terms and conditions for copying, distributing or modifying > the Library or works based on it. > > 10. Each time you redistribute the Library (or any work based on the > Library), the recipient automatically receives a license from the > original licensor to copy, distribute, link with or modify the Library > subject to these terms and conditions. You may not impose any further > restrictions on the recipients' exercise of the rights granted herein. > You are not responsible for enforcing compliance by third parties with > this License. > > 11. If, as a consequence of a court judgment or allegation of patent > infringement or for any other reason (not limited to patent issues), > conditions are imposed on you (whether by court order, agreement or > otherwise) that contradict the conditions of this License, they do not > excuse you from the conditions of this License. If you cannot > distribute so as to satisfy simultaneously your obligations under this > License and any other pertinent obligations, then as a consequence you > may not distribute the Library at all. For example, if a patent > license would not permit royalty-free redistribution of the Library by > all those who receive copies directly or indirectly through you, then > the only way you could satisfy both it and this License would be to > refrain entirely from distribution of the Library. > > If any portion of this section is held invalid or unenforceable under any > particular circumstance, the balance of the section is intended to apply, > and the section as a whole is intended to apply in other circumstances. > > It is not the purpose of this section to induce you to infringe any > patents or other property right claims or to contest validity of any > such claims; this section has the sole purpose of protecting the > integrity of the free software distribution system which is > implemented by public license practices. Many people have made > generous contributions to the wide range of software distributed > through that system in reliance on consistent application of that > system; it is up to the author/donor to decide if he or she is willing > to distribute software through any other system and a licensee cannot > impose that choice. > > This section is intended to make thoroughly clear what is believed to > be a consequence of the rest of this License. > > 12. If the distribution and/or use of the Library is restricted in > certain countries either by patents or by copyrighted interfaces, the > original copyright holder who places the Library under this License may add > an explicit geographical distribution limitation excluding those countries, > so that distribution is permitted only in or among countries not thus > excluded. In such case, this License incorporates the limitation as if > written in the body of this License. > > 13. The Free Software Foundation may publish revised and/or new > versions of the Lesser General Public License from time to time. > Such new versions will be similar in spirit to the present version, > but may differ in detail to address new problems or concerns. > > Each version is given a distinguishing version number. If the Library > specifies a version number of this License which applies to it and > "any later version", you have the option of following the terms and > conditions either of that version or of any later version published by > the Free Software Foundation. If the Library does not specify a > license version number, you may choose any version ever published by > the Free Software Foundation. > > 14. If you wish to incorporate parts of the Library into other free > programs whose distribution conditions are incompatible with these, > write to the author to ask for permission. For software which is > copyrighted by the Free Software Foundation, write to the Free > Software Foundation; we sometimes make exceptions for this. Our > decision will be guided by the two goals of preserving the free status > of all derivatives of our free software and of promoting the sharing > and reuse of software generally. > > NO WARRANTY > > 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO > WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. > EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR > OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY > KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE > IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE > LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME > THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. > > 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN > WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY > AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU > FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR > CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE > LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING > RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A > FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF > SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH > DAMAGES. > > END OF TERMS AND CONDITIONS > > How to Apply These Terms to Your New Libraries > > If you develop a new library, and you want it to be of the greatest > possible use to the public, we recommend making it free software that > everyone can redistribute and change. You can do so by permitting > redistribution under these terms (or, alternatively, under the terms of the > ordinary General Public License). > > To apply these terms, attach the following notices to the library. It is > safest to attach them to the start of each source file to most effectively > convey the exclusion of warranty; and each file should have at least the > "copyright" line and a pointer to where the full notice is found. > > > Copyright (C) > > This library is free software; you can redistribute it and/or > modify it under the terms of the GNU Lesser General Public > License as published by the Free Software Foundation; either > version 2.1 of the License, or (at your option) any later version. > > This library is distributed in the hope that it will be useful, > but WITHOUT ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > Lesser General Public License for more details. > > You should have received a copy of the GNU Lesser General Public > License along with this library; if not, write to the Free Software > Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > > Also add information on how to contact you by electronic and paper mail. > > You should also get your employer (if you work as a programmer) or your > school, if any, to sign a "copyright disclaimer" for the library, if > necessary. Here is a sample; alter the names: > > Yoyodyne, Inc., hereby disclaims all copyright interest in the > library `Frob' (a library for tweaking knobs) written by James Random Hacker. > > , 1 April 1990 > Ty Coon, President of Vice > > That's all there is to it! > ------------------------ end of proposed license ------------------ > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From gjhanna at gmail.com Sun Mar 11 14:21:17 2007 From: gjhanna at gmail.com (Greg Hanna) Date: Mon, 12 Mar 2007 09:21:17 +1300 Subject: [Rxtx] RXTX under VMWare server Message-ID: Hi Pavel, We are using RXTX under VMWare server in production, quite satisfactorily. We're using Red Hat Enterprise Server 4, and ... Whatever the "enterprise" VMWare product is. Regards, Greg H > Subject: [Rxtx] RXTX under VMWare server > To: rxtx at qbang.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello, world! > > I am writing application that communicates with modem via AT commands. > My OS is Linux Kubuntu Feisty Herd, to ensure that my application will > run properly under Windows XP I installed VMWare server. When I tried > to send AT command and evaluate modem answer under WinXP @ VMWare > server, I actually didn't receive anything. I think that VM settings > are right, because I do can communicate with modem by using standard > HyperTerminall as well as I can do on native Windows. > So, why RXTX doesn't work under VM, but works under Linux and pure > Windows XP (i tested it there) well? The send/receive method code > follows. [ ... snip ... ] -- Pavel Parkhomenko -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070311/4cebb6f9/attachment-0007.html From gergg at cox.net Sun Mar 11 23:39:19 2007 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 12 Mar 2007 00:39:19 -0500 Subject: [Rxtx] jsr status In-Reply-To: References: <45F327B0.2060004@udel.edu> Message-ID: <45F4E787.6050502@cox.net> Trent Jarvi wrote: > I can start going through the method interfaces later this week and giving > feedback. I would suggest that the JSR should not be too generic in > nature. USB->serial, Bluetooth->USB->serial, ... all implement kernel > drivers that intend to look like EIA232 ports at the kernel driver level. > > some ideas: > > EIA232PortInterface > TermiosInterface > SerialPortInterface > > Something that differentiates this from thing like USB, I2C, ... which > should not have to deal with legacy serial claiming to be the comm api. I'm going to throw out a suggestion, which I am mostly serious about. What would happen if we took the appropriate bits of the J2ME connector API, and just used that as the new COMM API so that finally JSE and JME had a common foundation for these kinds of things? Gregg Wonderly From ra85551 at gmail.com Mon Mar 12 09:08:37 2007 From: ra85551 at gmail.com (Pavel Parkhomenko) Date: Mon, 12 Mar 2007 18:08:37 +0300 Subject: [Rxtx] RXTX under VMWare server In-Reply-To: References: Message-ID: 2007/3/11, Trent Jarvi : > VMWare should not be a problem. I've used it in the past - though not > with a modem. Make sure nothing else is using the modem. Should any application use the modem, HyperTerminal won't be able to talk to the modem. But it actually can send and receive AT comands, while my application cannot :-( > Then look in > the rxtx 2.1 source for SimpleSnuV1.java in the contrib directory for an > example that should work. Thansk for the reference. I examined that example and found that there's no significant differences between my read/write implementation and that one, except that SimpleSnuV1 listens for serialEvent's, but not for sake of data retrieval, just for printing them out - I don't know why ;-) > Note that modems could care less what OS is on top. If you are trying to > match new lines to the OS and sending it to the mode for AT commands, > thats probably a mistake. I do send strings to serial port, not to OS, and do try to get answers back. If it is the mistake, what's the right way? > Also it would not hurt to print out the > individual bytes that you are sending to make sure they did not get > mangled along the path. Yeah, I am printing these bytes before doing write, but it means that I only see what I intend to write. How can I ensure that these bytes have gone out of the box and reached my modem? BTW, I found that my send/receive method is complex enough, so I've rewritten it. Please, see the following code and point any mistakes, because I don't know where can they remain yet. private static final int LARGE_TIMEOUT = 15000; private static final int SMALL_TIMEOUT = 500; ... private String sendATCommand(String command, String waitFor, boolean isRegex, boolean isAddCRLF) throws BeaconConnectException { byte[] buffer = new byte[512]; int offset; String result = ""; try { if (waitFor != null) { serialPort.enableReceiveTimeout(LARGE_TIMEOUT); } else { serialPort.enableReceiveTimeout(SMALL_TIMEOUT); } if (command != null) { OutputStream serialOutput = serialPort.getOutputStream(); if (isAddCRLF) { command += "\r\n"; } System.out.println(command); serialOutput.write(command.getBytes()); } offset = 0; InputStream serialInput = serialPort.getInputStream(); while (serialInput.available() != -1) { int bytesRead = serialInput.read(buffer, offset, buffer.length - offset); if (bytesRead == 0) { break; } offset += bytesRead; result = new String(buffer, 0, offset).trim(); if (waitFor != null) { System.out.println(result); if (isRegex && result.matches(waitFor) || result.contains(waitFor)) { break; } } } } catch (UnsupportedCommOperationException e) { throw new MyException("unsupported operation"); } catch (IOException e) { throw new MytException("serial I/O error"); } return result; } -- Pavel Parkhomenko From clayno at hotpop.com Thu Mar 15 02:47:34 2007 From: clayno at hotpop.com (Christopher Layno) Date: Thu, 15 Mar 2007 16:47:34 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi, we're using the latest release of rxtx (2.1-7r2) for our system that has two applications using the library. one application sends requests to the modem while the other simply checks the modem status. we deployed our system on a pentium machine with red hat linux 9.0 installed. now the problem arises when these two applications try to access the same modem at the same time. one of them will eventually have to throw the PortInUseException as shown below: 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException gnu.io.PortInUseException: root PID = 743 Program = java root PID = 743 Program = java root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) this was expected. what we didn't expect though was that if we repeat the scenario 5 times, always 5 times, the application would also throw a VM error: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4473CD21 Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so Current Java thread: at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) - locked <0x44cfd4c8> (a gnu.io.CommPortIdentifier) at ************ at ************ - locked <0x4476a468> (a **********) at ************ at ************ at ************ at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java :261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages( TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run( TCPTransport.java:701) at java.lang.Thread.run(Thread.java:534) note: i replaced some sensitive data with asterisks our team has looked everywhere on the internet, including your mail archives, for a solution to this problem but to no avail. i really hope you could help us out on this one. thanks in advance! best regards, chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070315/1936460a/attachment-0007.html From tjarvi at qbang.org Fri Mar 16 04:30:25 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 04:30:25 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: On Thu, 15 Mar 2007, Christopher Layno wrote: > hi, > > we're using the latest release of rxtx (2.1-7r2) for our system that has two > applications using the library. one application sends requests to the modem > while the other simply checks the modem status. we deployed our system on a > pentium machine with red hat linux 9.0 installed. > > now the problem arises when these two applications try to access the same > modem at the same time. one of them will eventually have to throw the > PortInUseException as shown below: > > 2007/03/15 13:30:42 [ERROR] *************()--PortInUseException > gnu.io.PortInUseException: root PID = 743 Program = java root PID = > 743 Program = java root PID = 743 Program = ??? root PID = 743 Program > = ??? root PID = 743 Program = ??? root PID = 743 Program = ??? root > PID = 743 Program = ??? root PID = 743 Program = ??? > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > > this was expected. what we didn't expect though was that if we repeat the > scenario 5 times, always 5 times, the application would also throw a VM > error: > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x4473CD21 > Function=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner+0x41 > Library=/****/*****/j2sdk1.4.2_06/jre/lib/i386/librxtxSerial.so > > Current Java thread: > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native > Method) Hi Chris The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. The code is originally by Werner Almesberger. He gave us permission to use it in rxtx. You might look at what has changed since 1998 in his fuser application. Or you can just do like other OSs and do the following in fuserImp.c JNIEXPORT jstring JNICALL Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv *env, jobject obj, jstring arg) { return (*env)->NewStringUTF(env, "Unknown Application"); } It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. -- Trent Jarvi tjarvi at qang.org From Adrien.TOS at ingenico.com Fri Mar 16 05:11:12 2007 From: Adrien.TOS at ingenico.com (Adrien TOS) Date: Fri, 16 Mar 2007 12:11:12 +0100 Subject: [Rxtx] [rxtx-2.1-7-bins-r2, Win XP, JDK 1.5] : Receive timeout precision is bad Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B7903CBC312@frsnprexc1.usr.ingenico.loc> Hi, First, here is our testing environment: rxtx : rxtx-2.1-7-bins-r2 OS : Win XP JDK : 1.5 We run into problems with the receive timeout precision of the rxtx library. Note: the same tests run perfectly OK on a linux platform with the driver rxtx-2.1-7-bins-r2/Linux/i686-unknown-linux-gnu/librxtxSerial.so, no error was detected at all. Here is the test: First we set the receive timeout by calling: port_.enableReceiveTimeout(timeout); Then we wait for some data: port_.getInputStream().read(buffer); Test 1: wait for incoming data for 1000 ms (1 sec) Result: OK, read() returns after 1015 ms Test 2: wait for incoming data for 10000 ms (10 secs) Result: OK, read() returns after 10005 ms Test 3: wait for incoming data for 30000 ms (30 secs) Result: KO, read() returns after 30908 ms Test 4: wait for incoming data for 50000 ms (50 secs) Result: KO, read() returns after 73347 ms <== very bad, 73 secs instead of 50 secs. Test 4: wait for incoming data for 60000 ms (1 minute) Result: KO, read() returns after 61913 ms Test 5: wait for incoming data for 120000 ms (2 minutes) Result: KO, read() returns after 123492 ms Test 6: wait for incoming data for 180000 ms (3 minutes) Result: KO, read() returns after 16547 ms <== very bad, 16,5 secs instead of 180 secs. Test 7: wait for incoming data for 240000 ms (4 minutes) Result: KO, read() returns after 192600 ms <== very bad, 192,6 secs instead of 240 secs. Test 7: wait for incoming data infinitely, call port_.disableReceiveTimeout(); Result: KO, read() returns immediately! <== should wait forever until data comes in? Have you ever experienced such problems? Is this a known bug and are there any possible workarounds? Thanks and regards, AT About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070316/972ab214/attachment-0007.html From joachim at buechse.de Fri Mar 16 05:13:24 2007 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 16 Mar 2007 12:13:24 +0100 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: References: Message-ID: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: > The psmisc code is some older code that looks in /proc to figure > out who > is using the port. It reports "Port is in use by tjarvi..." type of > information. It may be that the /proc layout has changed. We only do > this on Linux and I question how usefull it is. > ... > > It would be nice if the fuser code became part of a shared library in > distributions so we did not have to worry about changes in /proc. From tjarvi at qbang.org Fri Mar 16 16:36:29 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 16 Mar 2007 16:36:29 -0600 (MDT) Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Fri Mar 16 16:02:23 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 16 Mar 2007 18:02:23 -0400 Subject: [Rxtx] PortInUseException and VM error... In-Reply-To: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> References: <65ACB538-A2E3-4542-A49D-89CF26C0F58C@buechse.de> Message-ID: Not all platforms are Unix based. Also mixing native library usage and command-line calls is not an elegant solution, IMHO. One or the other, but not both. Andre On 16-Mar-07, at 07:13 , Joachim Buechse wrote: > What about using lsof as a client "library" for info about used ports > - it should be available on most unix installations nowadays. > - it returns the process name + number as well as the user. > - it is spawned as a process, so should it crash the VM wont > > It would only be called when a port open fails, so the load should be > neglectable. > It could be called from the Java code, so the implementation is > trivial. > > It is a bit unusual to call an external "application" from within a > library, but... > > Regards, > Joachim > > On 16.03.2007, at 11:30, Trent Jarvi wrote: >> The psmisc code is some older code that looks in /proc to figure >> out who >> is using the port. It reports "Port is in use by tjarvi..." type of >> information. It may be that the /proc layout has changed. We >> only do >> this on Linux and I question how usefull it is. >> > ... >> >> It would be nice if the fuser code became part of a shared library in >> distributions so we did not have to worry about changes in /proc. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From clayno at hotpop.com Sun Mar 18 22:17:28 2007 From: clayno at hotpop.com (Christopher Layno) Date: Mon, 19 Mar 2007 12:17:28 +0800 Subject: [Rxtx] PortInUseException and VM error... Message-ID: hi everyone, thank you so much for your replies. they were really helpful. anyway, before i sent the email, my team was already implementing a temporary solution by using joachim's suggestion. we invoked a lsof command from our java code although i share the same concern with trent and andre-john about portability issues. that's why i said it's just temporary. my superiors have yet to approve our bug fix. so my question now is this: is recompiling the rxtx source code the only way to solve this problem? because if it's the only solution, then i think my superiors would rather have a new release from the rxtx community itself that fixes this bug(?) rather than have my team recompile the source code. best regards, chris Trent Jarvi wrote: Hi Joachim It would be nice to have that functionality but calling the program introduces too many issues imho. Explaining to someone why rxtx invoked a rogue lsof does not sound very interesting. On Fri, 16 Mar 2007, Joachim Buechse wrote: What about using lsof as a client "library" for info about used ports - it should be available on most unix installations nowadays. - it returns the process name + number as well as the user. - it is spawned as a process, so should it crash the VM wont It would only be called when a port open fails, so the load should be neglectable. It could be called from the Java code, so the implementation is trivial. It is a bit unusual to call an external "application" from within a library, but... Regards, Joachim On 16.03.2007, at 11:30, Trent Jarvi wrote: The psmisc code is some older code that looks in /proc to figure out who is using the port. It reports "Port is in use by tjarvi..." type of information. It may be that the /proc layout has changed. We only do this on Linux and I question how usefull it is. ... It would be nice if the fuser code became part of a shared library in distributions so we did not have to worry about changes in /proc. _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/l